The object-client.js file is now a proper protocol.js front,
but is still named after a client.
This is confusing, so we rename and move the file next to other
fronts, and update all consumers to the new terminology.
Differential Revision: https://phabricator.services.mozilla.com/D49878
--HG--
rename : devtools/client/debugger/packages/devtools-reps/src/object-inspector/tests/__mocks__/object-client.js => devtools/client/debugger/packages/devtools-reps/src/object-inspector/tests/__mocks__/object-front.js
rename : devtools/shared/client/object-client.js => devtools/shared/fronts/object.js
extra : moz-landing-system : lando
`preEvent` isn't used anymore, but was somehow
replaced by `before`. This patch remove all the
mentions of `preEvent`, and tries to document
what can be done with `before`.
Differential Revision: https://phabricator.services.mozilla.com/D48068
--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 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
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 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
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:
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
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
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