When debugging contexts running from the system compartment, the debugger has
to be loaded in a dedicated Loader, with invisibleToDebugger flag turned on.
This ensures that the Debugger API is going to be used from a distinct system
compartment. Otherwise it may be used from the same compartment than the page
we are debugging.
Differential Revision: https://phabricator.services.mozilla.com/D14957
--HG--
extra : moz-landing-system : lando
Now that form argument is no longer used by any front to set its actor ID,
we can remove this argument.
Have a particular look at:
* devtools/client/shared/test/test-actor-registry.js
which was the last Front to be manually instantiated and need some tweaks,
* canvas head.js to create canvas front via getFront,
* RDM manager.js, which requires the EmulationFront to be self managed.
Depends on D17615
Differential Revision: https://phabricator.services.mozilla.com/D17616
--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
Remove all actorid checks in actors and fronts as we never pass a defined `detail` argument in them.
Only domstylerule and node are using detail and that, always with detail="actorid".
Also remove ctx and detail in Front constructor as that's not used by these two actors.
Depends on D17612
Differential Revision: https://phabricator.services.mozilla.com/D17613
--HG--
extra : moz-landing-system : lando
None of our actor define a `formType` in its specification.
This feature has never been used, so remove it and its test.
Differential Revision: https://phabricator.services.mozilla.com/D17612
--HG--
extra : moz-landing-system : lando
With all the dependency removed this pref can be safely removed.
Depends on D17574
Differential Revision: https://phabricator.services.mozilla.com/D17575
--HG--
extra : moz-landing-system : lando
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
We never really tried to cleanup the DebuggerServer and so a few tests require some tweaks
to acknowledge that once the last connection drop (typically, we close the toolbox or target),
the server is destroyed and dynamically registered actors are also destroyed.
I think it is great to consider that everything is cleaned up as we may followup to destroy
the whole loader.
Depends on D16961
Differential Revision: https://phabricator.services.mozilla.com/D16962
--HG--
extra : moz-landing-system : lando
These tests were using chrome mochitest which forces the test page to be running in chrome and in parent process.
This doesn't reflect typical setup where the page runs unprivileged in content process.
Also, with the current bug, the pages running in system principal will be debugged with a special setup.
Actors will be run with modules loaded in a distinct loader in order to be executed
in a distinct compartment, distinct from the shared system principal compartment.
That a prerequisite for the Debugger API. It has to run in a distinct compartment than its debuggee.
Depends on D16825
Differential Revision: https://phabricator.services.mozilla.com/D16826
--HG--
rename : devtools/server/tests/mochitest/animation-data.html => devtools/server/tests/browser/animation-data.html
rename : devtools/server/tests/mochitest/test_inspector-mutations-childlist.html => devtools/server/tests/browser/browser_inspector-mutations-childlist.js
rename : devtools/server/tests/mochitest/inspector-helpers.js => devtools/server/tests/browser/inspector-helpers.js
extra : moz-landing-system : lando
This test was using chrome mochitest which forces the test page to be running in chrome and in parent process.
This doesn't reflect typical setup where the page runs unprivileged in content process.
Also, with the current bug, the pages running in system principal will be debugged with a special setup.
Actors will be run with modules loaded in a distinct loader in order to be executed
in a distinct compartment, distinct from the shared system principal compartment.
That a prerequisite for the Debugger API. It has to run in a distinct compartment than its debuggee.
Depends on D16824
Differential Revision: https://phabricator.services.mozilla.com/D16825
--HG--
extra : moz-landing-system : lando
If any callback fired by DebuggerClient.close ends up calling close again, it will introduce an infinite loop.
Depends on D15826
Differential Revision: https://phabricator.services.mozilla.com/D15827
--HG--
extra : moz-landing-system : lando
This converts the tabmodalprompt binding to a class, to be constructed along side with the element
by TabModalPromptBox.
TabModalPromptBox will keep the instances in a map and pass it to the callers, instead of the element.
The tests and callers can access the class instance by passing the element reference to the map.
Differential Revision: https://phabricator.services.mozilla.com/D15505
--HG--
rename : toolkit/components/prompts/content/tabprompts.xml => toolkit/components/prompts/content/tabprompts.jsm
extra : moz-landing-system : lando
With same-compartment chrome globals these would end up in the same compartment.
We need to prevent that because the debugger doesn't support it.
Differential Revision: https://phabricator.services.mozilla.com/D15093
--HG--
extra : moz-landing-system : lando
This will help getting rid of another usage of Target.form.
And also helps instantiating only one WebConsole client.
Once WebConsole becomes a front, we can replace all the target.activeTab
to target.getFront("console").
Differential Revision: https://phabricator.services.mozilla.com/D14278
--HG--
extra : moz-landing-system : lando
The debuggee and debugger must be in separate compartments. I tried using a null
principal for the debuggee, but that doesn't work because some of these tests
use Components or do interesting principal-related things with the sandbox (see
test_objectgrips-17.js for an example of this).
Differential Revision: https://phabricator.services.mozilla.com/D14254
--HG--
extra : moz-landing-system : lando
This cleanup will help next refactorings.
Note that attachTestThread and attachTestTabAndResume are still using the callback style
as it is still being used by tests that aren't using threadClientTest helper.
MozReview-Commit-ID: 6FvoDtzEBmL
Depends on D13901
Differential Revision: https://phabricator.services.mozilla.com/D13902
--HG--
extra : moz-landing-system : lando
This isn't removing listTabs calls as these tests were using attachTestTab,
but all these tests are using testGlobal helper whereas they don't have to if they were using threadClientTest helper.
MozReview-Commit-ID: FPtYlDvYUeD
Depends on D13900
Differential Revision: https://phabricator.services.mozilla.com/D13901
--HG--
extra : moz-landing-system : lando
This isn't thread client test, but here we could share some more code with the memory tests
and use Target objects to retrieve the fronts.
MozReview-Commit-ID: C9S1VjTLrSF
Depends on D13899
Differential Revision: https://phabricator.services.mozilla.com/D13900
--HG--
extra : moz-landing-system : lando
All these tests are clearly copy pasting existing threadClientTest helper.
They might run as well against workers but today we don't run them there, so I used the doNotRunWorker flag.
MozReview-Commit-ID: 7k1lJ06WeGZ
Differential Revision: https://phabricator.services.mozilla.com/D13899
--HG--
extra : moz-landing-system : lando
Depends on D13137. I could use help to write the test in a better.
I believe there is a cleaner way to create the front here?
I also had other suggestions for making the fronts more robust in the bug.
Let me know if you think I should try to investigate them more.
Differential Revision: https://phabricator.services.mozilla.com/D13138
--HG--
extra : moz-landing-system : lando
These tests are calling listTabs, but that is no longer necessary thanks to rootForm
being automatically managed within RootFront.
MozReview-Commit-ID: AmC6dTIJjiY
Depends on D12732
Differential Revision: https://phabricator.services.mozilla.com/D12733
--HG--
extra : moz-landing-system : lando
I also removed the get root form leftover.
MozReview-Commit-ID: DxPwG9a5YAG
Depends on D12731
Differential Revision: https://phabricator.services.mozilla.com/D12732
--HG--
extra : moz-landing-system : lando
There is 4 patterns here:
* Tests using attachThreadActorForUrl like event-listeners ones. I augmented this helper method to call TargetFactory.
* Tests using attachTargetActorForUrl like debugger-statement, dbg-navigation and target-scoped-actor. Uses TargetFactory directly.
* Tests using connectDebuggerClient like navigateEvents and spaw_actor_in_parent. Uses TargetFactory directly.
* All the others, where creating DebuggerClient on their own, and calling listTabs+attachTarget. They now use TargetFactory directly.
A note about webconsole-helpers, only consoleClient attribute was used from tests using this helper.
Also, in various tests I remove the call to client.destroy, that's because shared-head will
close all the tabs/toolboxes and it should lead to target/client destruction.
Finally, debugger-statement now request the thread actor via the client instead of manual request,
it should help the refactoring to a front!
MozReview-Commit-ID: 2ah4UmSjuoi
Depends on D12730
Differential Revision: https://phabricator.services.mozilla.com/D12731
--HG--
extra : moz-landing-system : lando
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
Adapt to the new returned value of listAddons
and also always call it from RootFront instead of DebuggerClient.
Fix the spec in order to expose reload on the front (it was a miss from a previous patch).
MozReview-Commit-ID: AQ5EOQEqnxX
Depends on D12575
Differential Revision: https://phabricator.services.mozilla.com/D12576
--HG--
extra : moz-landing-system : lando
Adapt to the new returned value of listAddons
and also always call it from RootFront instead of DebuggerClient.
Fix the spec in order to expose reload on the front (it was a miss from a previous patch).
MozReview-Commit-ID: AQ5EOQEqnxX
Depends on D12575
Differential Revision: https://phabricator.services.mozilla.com/D12576
--HG--
extra : moz-landing-system : lando
There is a lot of code being copy paste in all these tests
and as I'm most likely going to change things around them in the near future
regarding fission, it would be better if we start sharing more code.
After this there is still a couple of copy paste code (but way less!):
* breakpoints: wait a paused event and eval a custom script in a sandbox
* object grips: set the security.allow_eval_with_system_principal pref, eval stopMe and wait for paused
* stepping: use executeOnNextTickAndWaitForPause to eval a custom script and wait for pause while doing this only on next tick
There is most likely more to share, but at least this isn't framework code, but now only code specific to the debugger.
MozReview-Commit-ID: JgD389cas2j
Depends on D12309
Differential Revision: https://phabricator.services.mozilla.com/D12310
--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 removes the dom.webcomponents.shadowdom.enabled pref and all its
references, including the following functions:
* nsContentUtils::IsShadowDOMEnabled()
* nsIDocument::IsShadowDOMEnabled()
* nsDocument::IsShadowDOMEnabled(JSContext* aCx, JSObject* aGlobal)
* nsDocument::IsShadowDOMEnabled(const nsINode* aNode)
* nsTextNode::IsShadowDOMEnabled(JSContext* aCx, JSObject* aObject)
This function is renamed and updated to nsDocument::IsCallerChromeOrAddon():
* nsDocument::IsShadowDOMEnabledAndCallerIsChromeOrAddon(JSContext* aCx, JSObject* aObject)
I didn't change the tests that load Shadow DOM tests in an iframe, in the interest of keeping hg annotation history.
Differential Revision: https://phabricator.services.mozilla.com/D11183
--HG--
extra : moz-landing-system : lando
This patch removes the dom.webcomponents.shadowdom.enabled pref and all its
references, including the following functions:
* nsContentUtils::IsShadowDOMEnabled()
* nsIDocument::IsShadowDOMEnabled()
* nsDocument::IsShadowDOMEnabled(JSContext* aCx, JSObject* aGlobal)
* nsDocument::IsShadowDOMEnabled(const nsINode* aNode)
* nsTextNode::IsShadowDOMEnabled(JSContext* aCx, JSObject* aObject)
This function is renamed and updated to nsDocument::IsCallerChromeOrAddon():
* nsDocument::IsShadowDOMEnabledAndCallerIsChromeOrAddon(JSContext* aCx, JSObject* aObject)
I didn't change the tests that load Shadow DOM tests in an iframe, in the interest of keeping hg annotation history.
Differential Revision: https://phabricator.services.mozilla.com/D11183
--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
* browser_two_tabs.js, adapt to protocol.js exception on RDP error.
protocol.js throws strings instead of { error, message }.
* target-from-url.js, same, it made a test fail.
* browser_toolbox_tool_remote_reopen.js, ignore root front that isn't release on
toolbox close, but on client close.
* test_protocol_formtype.js, ensure that test root front isn't overridden
by regular root front's spec.
MozReview-Commit-ID: HCuyZTQpaCt
Depends on D8825
Differential Revision: https://phabricator.services.mozilla.com/D8983
--HG--
extra : moz-landing-system : lando
Depends on D8739.
This changeset updates calls to ok() that were most likely intended
for is(), but are not working as is.
Differential Revision: https://phabricator.services.mozilla.com/D8740
--HG--
extra : moz-landing-system : lando
This changeset updates all the test that were wrongly using ok() and wanted to
use is() AND for which the assert is still passing without any modification
required.
Differential Revision: https://phabricator.services.mozilla.com/D8739
--HG--
extra : moz-landing-system : lando
In this patch, I converted the call sites where there was an obvious target. I left out
those where there wasn't one... Should these be converted as well?
Depends on D8369
Differential Revision: https://phabricator.services.mozilla.com/D8374
--HG--
extra : moz-landing-system : lando
This is part 1 of bug 1497545, and covers the most difficult case, which is migrating
attachURL to something a bit more modern and easier to read. The goal is to make our tests more
consistant with our code base now, and keep these tests maintainable.
UPDATE: I will split this up, as it is too large to review in one pass
Differential Revision: https://phabricator.services.mozilla.com/D8369
--HG--
extra : moz-landing-system : lando
* browser_addons_debug_webextension_popup: It looks like frame-update events are now fired earlier.
I had to move the listener to an earlier step in order to make it work.
* helper_disable_cache + toolbox.js: this test wasn't correctly listening for reconfigure request's end.
Not clear how this test was passing before without high rate of intermittent...
* test_webextension-addon-debugging-connect.html: We can no longer listen for frame-update *before* the target object is created.
(because we now need a TabTarget object or the TargetFront and not just the DebuggerClient)
* Fix reload request in shadereditor which may still be pending after test ends.
MozReview-Commit-ID: 49qvWSCn6nq
Depends on D8066
Differential Revision: https://phabricator.services.mozilla.com/D7460
--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
I also made its argument mandatory, so that later in root spec we can use a non-nullable number.
MozReview-Commit-ID: BUPgI1ww1gC
Differential Revision: https://phabricator.services.mozilla.com/D8141
--HG--
extra : moz-landing-system : lando
* browser_addons_debug_webextension_popup: It looks like frame-update events are now fired earlier.
I had to move the listener to an earlier step in order to make it work.
* helper_disable_cache + toolbox.js: this test wasn't correctly listening for reconfigure request's end.
Not clear how this test was passing before without high rate of intermittent...
* test_webextension-addon-debugging-connect.html: We can no longer listen for frame-update *before* the target object is created.
(because we now need a TabTarget object or the TargetFront and not just the DebuggerClient)
MozReview-Commit-ID: 49qvWSCn6nq
Depends on D8066
Differential Revision: https://phabricator.services.mozilla.com/D7460
--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
Instead of requiring all TargetFactory.forRemoteTab to compute isBrowsingContext flag,
we can compute it out of the actor's form as we know which types are browsing context
inherited or not.
MozReview-Commit-ID: H5zLo5nZSm6
Differential Revision: https://phabricator.services.mozilla.com/D7413
--HG--
extra : moz-landing-system : lando
Summary:
create LazyActorClass based off ObservedActorFactory and RegisterdFactory classes for use in RootActor and BrowsingContextActor;
Depends on D6468
Reviewers: ochameau
Reviewed By: ochameau
Bug #: 1473513
Differential Revision: https://phabricator.services.mozilla.com/D6470
--HG--
rename : devtools/server/actors/common.js => devtools/shared/protocol/lazy-pool.js
extra : rebase_source : 09a1c8eac3cbb5856a5e3e61a1c0540efe32e5bd
Functions using 'defer' for promises are being switched to the 'new Promise' syntax. This is for changes in devtools/server/tests/mochitest.
Differential Revision: https://phabricator.services.mozilla.com/D6618
--HG--
extra : moz-landing-system : lando
create LazyActorClass based off ObservedActorFactory and RegisterdFactory classes for use in RootActor and BrowsingContextActor;
Depends on D6468
Differential Revision: https://phabricator.services.mozilla.com/D6470
--HG--
rename : devtools/server/actors/common.js => devtools/shared/protocol/lazy-pool.js
extra : moz-landing-system : lando
Summary:
This method isn't specific to tabs. It can attach to any "target" actor that inherits from BrowsingContextActor.
Depends On D6161
Reviewers: yulia!
Tags: #secure-revision
Bug #: 1485676
Differential Revision: https://phabricator.services.mozilla.com/D6162
MozReview-Commit-ID: Exz5fWyWyfN
Summary:
Now that all the "remoting" of this method has been moved to TargetFactory.createTargetForTab,
we should rename this method to what it does now. It mostly call attach requests
of the target actor and its child console actor.
It also "connect" the webextension target actor, but I would like to eventually move that
outside of TabTarget.attach, like makeRemote.
Depends On D4078
Reviewers: yulia!
Tags: #secure-revision
Bug #: 1485676
Differential Revision: https://phabricator.services.mozilla.com/D6161
MozReview-Commit-ID: KmFi1LIUBga
Summary:
This method isn't specific to tabs. It can attach to any "target" actor that inherits from BrowsingContextActor.
Depends On D6161
Reviewers: yulia!
Tags: #secure-revision
Bug #: 1485676
Differential Revision: https://phabricator.services.mozilla.com/D6162
MozReview-Commit-ID: Exz5fWyWyfN
Summary:
Now that all the "remoting" of this method has been moved to TargetFactory.createTargetForTab,
we should rename this method to what it does now. It mostly call attach requests
of the target actor and its child console actor.
It also "connect" the webextension target actor, but I would like to eventually move that
outside of TabTarget.attach, like makeRemote.
Depends On D4078
Reviewers: yulia!
Tags: #secure-revision
Bug #: 1485676
Differential Revision: https://phabricator.services.mozilla.com/D6161
MozReview-Commit-ID: KmFi1LIUBga
This method isn't specific to tabs. It can attach to any "target" actor that inherits from BrowsingContextActor.
Depends On D6161
Differential Revision: https://phabricator.services.mozilla.com/D6162
--HG--
extra : moz-landing-system : lando
Now that all the "remoting" of this method has been moved to TargetFactory.createTargetForTab,
we should rename this method to what it does now. It mostly call attach requests
of the target actor and its child console actor.
It also "connect" the webextension target actor, but I would like to eventually move that
outside of TabTarget.attach, like makeRemote.
Depends On D4078
Differential Revision: https://phabricator.services.mozilla.com/D6161
--HG--
extra : moz-landing-system : lando
Summary:
This method isn't specific to tabs. It can attach to any "target" actor that inherits from BrowsingContextActor.
Depends On D6161
Reviewers: yulia!
Tags: #secure-revision
Bug #: 1485676
Differential Revision: https://phabricator.services.mozilla.com/D6162
MozReview-Commit-ID: Exz5fWyWyfN
Summary:
Now that all the "remoting" of this method has been moved to TargetFactory.createTargetForTab,
we should rename this method to what it does now. It mostly call attach requests
of the target actor and its child console actor.
It also "connect" the webextension target actor, but I would like to eventually move that
outside of TabTarget.attach, like makeRemote.
Depends On D4078
Reviewers: yulia!
Tags: #secure-revision
Bug #: 1485676
Differential Revision: https://phabricator.services.mozilla.com/D6161
MozReview-Commit-ID: KmFi1LIUBga
This new API allows to instanciate an actor in the parent process from actors running in the parent process.
The created actors are returned to the client from the actors running in content,
but after that, the client communicates directly with the created actors running in the parent process.
MozReview-Commit-ID: 5B3wRQ94UEx
--HG--
extra : rebase_source : 808ea31fe8a467d0185fc27056c6524873cddbce
The term "tab actor" was used ambiguously to mean either the "target actor
representing a tab" or "a child actor of the tab target actor" (such as the
console actor). Here we rename the second case to "target-scoped actor".
Differential Revision: https://phabricator.services.mozilla.com/D1760
--HG--
rename : devtools/client/debugger/test/mochitest/browser_dbg_tabactor-01.js => devtools/client/debugger/test/mochitest/browser_dbg_target-scoped-actor-01.js
rename : devtools/client/debugger/test/mochitest/browser_dbg_tabactor-02.js => devtools/client/debugger/test/mochitest/browser_dbg_target-scoped-actor-02.js
The term "tab actor" was used ambiguously to mean either the "target actor
representing a tab" or "a child actor of the tab target actor" (such as the
console actor). Here we rename the second case to "target-scoped actor".
Differential Revision: https://phabricator.services.mozilla.com/D1760
--HG--
rename : devtools/client/debugger/test/mochitest/browser_dbg_tabactor-01.js => devtools/client/debugger/test/mochitest/browser_dbg_target-scoped-actor-01.js
rename : devtools/client/debugger/test/mochitest/browser_dbg_tabactor-02.js => devtools/client/debugger/test/mochitest/browser_dbg_target-scoped-actor-02.js
Alexandre Poirot
Brian Grinstead
Cosmin Sabou
Timothy Guan-tin Chien
Jason Laster
Kris Maglione
vinoth
yulia
Margareta Eliza Balazs
Brian Hackett
Oriol Brufau
Logan Smyth
Jan de Mooij
Anshul Malik
Sylvestre Ledru
Julian Descottes
Yura Zenevich
Narcis Beleuzu
Andreea Pavel
Nazım Can Altınova
Daisuke Akatsuka
Jim Blandy
Mark Banner
Tim Nguyen
Bogdan Tara
Brindusan Cristian
Noemi Erli
Ciure Andrei
Gurzau Raul
Jason Laster
sreeise
Zibi Braniecki
arthur.iakab
shindli
Bobby Holley
Belen Albeza
Tom Schuster
Coroiu Cristina
Micah Tigley
Boris Zbarsky
Benjamin Bouvier
J. Ryan Stinnett
Dorel Luca
Joel Maher
Emilio Cobos Álvarez