These are generally:
- Code comments to browser.xhtml
- Testcases, assertions that were mostly using browser.xul as a generic chrome URL
- References to the browser.xul path in tree
Differential Revision: https://phabricator.services.mozilla.com/D33208
Fix the broken link in docs to devtools. The link to chapter about testing.
Differential Revision: https://phabricator.services.mozilla.com/D22867
--HG--
extra : moz-landing-system : lando
There is one spot I am unsure about, and that is the test:
devtools/server/tests/unit/test_threadlifetime-06.js -- should this be kept or do we want to remove
it as well?
Differential Revision: https://phabricator.services.mozilla.com/D21674
--HG--
extra : moz-landing-system : lando
This just adds a line to the documentation to make console.log outputs easier to find by adding an emoji.
Differential Revision: https://phabricator.services.mozilla.com/D17984
--HG--
extra : moz-landing-system : lando
This feature is only used by node and domrulestyle actors and that, only for actor ID.
Instead of this, support this "pass only actor ID rather than full form" feature
in a more dedicated way.
We might followup on that to clarify/simplify doing this: passing only the actor ID
rather than its full form.
Depends on D17613
Differential Revision: https://phabricator.services.mozilla.com/D17614
--HG--
extra : moz-landing-system : lando
This should be rather safe. We can do more refactoring and renaming once LegacyExtension support is fully removed (ie Fx 65 hits release)
Differential Revision: https://phabricator.services.mozilla.com/D15383
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
For now, we only pass { actor } for all tab target fronts created via DebuggerClient.attachTarget,
whereas parent process target fronts were passing the full form from RootFront.getProcess.
MozReview-Commit-ID: 1H2NxFv8glY
Differential Revision: https://phabricator.services.mozilla.com/D12730
--HG--
extra : moz-landing-system : lando
This was only used by test and isn't much useful.
MozReview-Commit-ID: DeIimVmMOOs
Depends on D11623
Differential Revision: https://phabricator.services.mozilla.com/D11624
--HG--
extra : moz-landing-system : lando
This patch introduces 2 new prefs:
- devtools.console.stdout.chrome: if true, console API writes on stdout when
used by chrome code
- devtools.console.stdout.content: console API write on stdout when used by
content code.
This was only used by test and isn't much useful.
MozReview-Commit-ID: DeIimVmMOOs
Depends on D11623
Differential Revision: https://phabricator.services.mozilla.com/D11624
--HG--
extra : moz-landing-system : lando
* debugger-controller and events.js are special and require to support two cases because this is
the only production codepath that can have a TabTarget or a WorkerTarget.
Thus, leading to either TargetFront or WorkerClient on target.activeTab.
* webide.js doesn't need to listen for tabNavigated, this is redundant with tabListChanged.
* application's initializer. In case you are wondering this code can't be spawn against a WorkerTarget.
The application panel doesn't work in worker toolboxes.
* The code modified in target is in TabTarget, so we don't have to support the WorkerClient case, we always have a TargetFront here.
* I tried to update the doc file the best I can but this all feel outdated.
MozReview-Commit-ID: 2hGchebfIub
Depends on D7458
Differential Revision: https://phabricator.services.mozilla.com/D7459
--HG--
extra : moz-landing-system : lando
* debugger-controller and events.js are special and require to support two cases because this is
the only production codepath that can have a TabTarget or a WorkerTarget.
Thus, leading to either TargetFront or WorkerClient on target.activeTab.
* webide.js doesn't need to listen for tabNavigated, this is redundant with tabListChanged.
* application's initializer. In case you are wondering this code can't be spawn against a WorkerTarget.
The application panel doesn't work in worker toolboxes.
* The code modified in target is in TabTarget, so we don't have to support the WorkerClient case, we always have a TargetFront here.
* I tried to update the doc file the best I can but this all feel outdated.
MozReview-Commit-ID: 2hGchebfIub
Depends on D7458
Differential Revision: https://phabricator.services.mozilla.com/D7459
--HG--
extra : moz-landing-system : lando
