When removing all declarations from a rule via the Rule view, the authoredText value ends up as an empty string.
This patch ensures that the fallback cssText is not used in that case because that accidentally restores the whole declaration block when re-parsing the text of the rule.
Differential Revision: https://phabricator.services.mozilla.com/D14753
--HG--
extra : moz-landing-system : lando
When removing all declarations from a rule via the Rule view, the authoredText value ends up as an empty string.
This patch ensures that the fallback cssText is not used in that case because that accidentally restores the whole declaration block when re-parsing the text of the rule.
Differential Revision: https://phabricator.services.mozilla.com/D14753
--HG--
extra : moz-landing-system : lando
Now that the base Target class is managing the thread client,
we no longer have to send "newSource" on the target actor, and instead,
listen for newSource directly on the thread client.
We should probably align updatedSource and have this event being emitted on
the thread actor as well.
Depends on D18813
Differential Revision: https://phabricator.services.mozilla.com/D18814
--HG--
extra : moz-landing-system : lando
There is still some tight connection between ThreadClient and Target,
- Target.threadClient, which should ideally disappear in favor of
target.getFront("thread")
- Target.threadClient is manually nullified from ThreadClient.detach,
but that should disappear as well thanks to getFront.
Differential Revision: https://phabricator.services.mozilla.com/D18813
--HG--
extra : moz-landing-system : lando
When destroying the target, Target.destroy (for local tabs) only calls DebuggerClient.close,
which isn't going to call `detach`. But we still do need to unregister
the tabNavigated/frameUpdate listener to prevent unecessary event from firing.
Depends on D17609
Differential Revision: https://phabricator.services.mozilla.com/D17610
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
When destroying the target, Target.destroy (for local tabs) only calls DebuggerClient.close,
which isn't going to call `detach`. But we still do need to unregister
the tabNavigated/frameUpdate listener to prevent unecessary event from firing.
Depends on D17609
Differential Revision: https://phabricator.services.mozilla.com/D17610
--HG--
extra : moz-landing-system : lando
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
--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
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
--HG--
extra : moz-landing-system : lando
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
--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
Detect when nodes are scrollable on the actor side, and use this
information to display new [scrollable] markup-badges in the inspector.
Also track this dynimically so badges are added/removed when necessary.
Hide this behind a pref for now, until this gets tested by users and
validated.
Differential Revision: https://phabricator.services.mozilla.com/D17246
--HG--
extra : moz-landing-system : lando
[Bug 1512634](https://bugzilla.mozilla.org/show_bug.cgi?id=1512634) occurred because the Rule view marks CSS properties as overriden when they are not lowercase. This happens because `ElementStyle.markOverridden()` relies on computed properties. They get built using `CSSProperties.getSubproperties()`. If the input to that method is not lowercase, it doesn't match properties from the CSS database and returns an empty array. This has a side-effect of marking the property as overriden.
In this patch we allow users to type property names in any case, but we validate the lowercase version of them.
Differential Revision: https://phabricator.services.mozilla.com/D14568
--HG--
extra : moz-landing-system : lando
We were dipatching the "connect" request manually, whereas we should be using
protocol.js specifications. It also help getting rid of another use of "form"
instead of "front"/activeTab in Target class.
MozReview-Commit-ID: IOH4mDprAVL
Depends on D12577
Differential Revision: https://phabricator.services.mozilla.com/D12578
--HG--
extra : moz-landing-system : lando
I did a dedicated patch for converting both about:debuggings as it is slightly more
complex as we have to tweak redux data, wrappers, mocks.
This patch also convert a manual "reload" request being done by about:debugging
and instead use protocol.js front to do it.
Also, I moved isLegacyTemporaryExtension to the front as it depends on accessing the form
and it should be better to keep form processing to the fronts, if possible.
MozReview-Commit-ID: 16qZkuCBp9b
Depends on D12576
Differential Revision: https://phabricator.services.mozilla.com/D12577
--HG--
extra : moz-landing-system : lando
Razvan Caliman
Razvan Maries
Alexandre Poirot
yulia
Gabriel Luong
Gurzau Raul
Bogdan Tara
Sebastian Hengst
Patrick Brosset
Julian Descottes
Ciure Andrei
Logan Smyth
Cosmin Sabou