1449123 - The list of rules does not update when a sibling of an ancestor changes and that has an effect on the matching CSS rules

Status: NEW

(DevTools :: Inspector: Rules, defect, P2)

Description

[Patrick Brosset <:pbro>]

Here are 2 test cases:
- attachment 8961740 [details]
- attachment 8961747 [details]

They both demonstrate that the rule-view does not properly refresh the list of rules when a change happens somewhere else in the DOM that should impact the list of rules for the current element.

Indeed, when an element is selected in the inspector, we expect the list of rules to always be up to date with what actually applies to the element right now.
It works in some cases:
- when the element has an attribute changed, then the list of rules is refreshed, because this attribute may change which rules apply to it,
- when a parent element has an attribute changed too (see bug 1447736),
- or when a sibling has an attribute changed too (see bug 1447736).

However, we still need to also update when nodes are added or removed as siblings of ancestors. Or when attributes on siblings of ancestors are changed.

The logic for this is in devtools\client\inspector\shared\style-change-tracker.js but is quite simple for now. We don't have a mean of checking if the list of rules actually changed, so we basically force a refresh of the view anytime something interesting happens.

In this bug, we'll have to make the list of "interesting" things longer, which will make the rule-view refresh more frequently. It is time we think of a potentially more focused approach that avoids having to refresh in cases when really nothing changed:
- turning the rule-view to React might help, with the dom-diffing approach,
- or requesting the rules again and checking if they changed before updating,
- or having a special platform API that tells us when a re-style happened for a specific node. Note that this was discussed in bug 1447736 between bug 1447736 comment 4 and bug 1447736 comment 10.

Comment 1

[Patrick Brosset <:pbro>]

Here is a potential approach:

- remember the list of rules on the style actor,
- let the actor know which element is currently selected (just remember the last element for which we needed the rules),
- make the actor listen to any server-side event that might have an effect on the list of rules,
- when any of these event happen, call InspectorUtils.getCSSStyleRules again (on the node we stored), compare the returned list of rules with the list of rules we returned before
- if there's a difference, send the list of rules again as an event to the client-side

This way, we don't need any new platform API (which seems hard/impossible to do), we just call getCSSStyleRules over and over again whenever we think is important to do so, and we only send events to the client when something did change.
This would simplify the client-side logic greatly (we wouldn't need style-change-tracker.js anymore in fact I think).
And it would make sure the list of rules refreshes only when strictly necessary.