Some actors weren't using any specification. They now have to pass a bare minimal spec object.
Unifying them to the regular Actor interface helps merging constructor with initialize
and instantiate all the actors without any code branch.
Differential Revision: https://phabricator.services.mozilla.com/D169359
actorhasMethod had several technical limitations making it hard to use consistently. We now removed all the call sites for this method. This changeset removes the method and all its dependencies.
Differential Revision: https://phabricator.services.mozilla.com/D95861
This patch make it so the RootFront is created from its spec file,
like any other front.
Protocol xpcshell tests are modified to take these changes into account.
Differential Revision: https://phabricator.services.mozilla.com/D66597
This patch makes it so that all target fronts inherits from a Target class mixin.
We are using a mixin as fronts should inherit from a custom Front class,
which is augmented with its own RDP request and events defined in its spec.
(This is done via FrontClassWithSpec(spec))
Depends on D15830
Differential Revision: https://phabricator.services.mozilla.com/D15831
This patch makes it so that all target fronts inherits from a Target class mixin.
We are using a mixin as fronts should inherit from a custom Front class,
which is augmented with its own RDP request and events defined in its spec.
(This is done via FrontClassWithSpec(spec))
Depends on D15830
Differential Revision: https://phabricator.services.mozilla.com/D15831
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
Ideally, formAttributeName would be a field on the prototype of each front,
but unfortunately, Firefox doesn't support ES Class's fields yet. So it is
put as an instance attribute instead.
This patch streamline the manually set actorID and the retrieval of actor ID
from root or target front's form into `getFront` helper method.
So that all the specific related to the lazy actor is now inside of this helper.
It also moves the special "this.manage(this)" to this helper.
We might be able to followup on this one and finally have only the root front
being self managed. But the initialize method makes it hard.
Note the special tweak made to devtools/client/responsive.html/manager.js
Hopefully this can be removed once the target classes are merged.
Depends on D15832
Differential Revision: https://phabricator.services.mozilla.com/D17615
Only a couple of special cases where expecting to pass a full form object
as Front's second constructor argument.
Refactor them to ensure calling Front's form method instead in order to align
with typical protocol.js's behavior.
Depends on D17614
Differential Revision: https://phabricator.services.mozilla.com/D15832
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
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
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
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
Front.actor custom implementation is only used from Front class and doesn't match Pool's one behavior.
Front users would expect to see the one from Pool as it inherits from it.
MozReview-Commit-ID: 8plo2K5kEWq
Differential Revision: https://phabricator.services.mozilla.com/D11614
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
Since protocol.js catches exceptions and returns an appropriate
packet as a result, we can use this instead of returning manually
an error packet.
MozReview-Commit-ID: 6lREam5sEVs