We're flagging new added rule by adding a `userAdded` property on the StyleRule
form when the rule is added from the UI.
We then refactor `_onAddRule` so it only calls the server and stores the actorID
of the new rule.
Then, in `_createEditors`, if a rule has `userAdded`, and if we are waiting for
a user added rule, we focus the rule's selector.
We take this opportunity to emit a dedicated `new-rule-added` event instead of
relying on the more generic `ruleview-changed` that we previously had.
A few test are updated in consequence.
Differential Revision: https://phabricator.services.mozilla.com/D186463
We are already refreshing the view when the sidebar is selected (so for example,
going from the layout to the rules view), but we were not refreshing it when
selecting the panel (so for example, going from the styleeditor to the inspector,
while the rule view is the active sidebar panel).
While writing a test, I realized `CssRuleView#isPanelVisible` was always returning
true when the 3 pane mode is enabled, even if the inspector isn't the active tool,
which is incorrect, so I fixed it.
A test is added to ensure we covers this, by adding a stylesheet from the style editor.
Differential Revision: https://phabricator.services.mozilla.com/D185560
These three attributes are very large arrays and we could easily keep them
within the worker thread by exposing new dedicated method.
Differential Revision: https://phabricator.services.mozilla.com/D187436
Clarify which attributes are used only within the worker
and shouldn't be passed to the main thread.
Also clarify what are the usages of each attribute so that we can
more easily transfer some on-demand.
`callExpressions` wasn't used anywhere.
Differential Revision: https://phabricator.services.mozilla.com/D187401
The update script was mentioning a few manual actions that I made
explicit through patches, this should make further updates more robust.
Differential Revision: https://phabricator.services.mozilla.com/D187758
At the moment, the (regular) computed properties PropertyView are created at
panel initialization, and then are shown/hidden depending of the selected element.
The list of properties is gathered from the panel's window computed property,
and not from the content page one.
That means that we can't build PropertyView for custom property at initialization
time, but potentially each time the computed property is refreshed.
In order to minimize dom mutations, when the view is refreshed, we:
- only remove the custom properties that are not set on the selected node
- update the value for the custom properties that are still set
- create new PropertyView for custom properties that weren't previously set
In order to keep the list ordered, we have to compute the index to put the new
elements in the right position. This is a bit tedious, but seems to work well
for performance.
A test is added for checking those custom properties.
Differential Revision: https://phabricator.services.mozilla.com/D182994
This wasn't really used anymore.
We are fetching the database from the server runtime in order to support
remote debugging correctly, where frontend CSS may be different from debuggee CSS.
Differential Revision: https://phabricator.services.mozilla.com/D187492
This wasn't really used anymore.
We are fetching the database from the server runtime in order to support
remote debugging correctly, where frontend CSS may be different from debuggee CSS.
Differential Revision: https://phabricator.services.mozilla.com/D187492
This is technically web-exposed, but if we needed to introduce it for
compat we could always re-introduce it matching false.
Differential Revision: https://phabricator.services.mozilla.com/D186938
This is technically web-exposed, but if we needed to introduce it for
compat we could always re-introduce it matching false.
Differential Revision: https://phabricator.services.mozilla.com/D186938
