Bug 29016 – Editing a style rule's selector to be more specific doesn't reorder the sections

• Status: RESOLVED
• Resolution: INVALID
• Component: Web Inspector (Deprecated)

[Timothy Hatcher]

Created attachment 39153 [details]
Bug

If you edit a style rule's selector to be more specific, the style rule sections are not reordered to show the new cascade. This also means we don't cross out the correct overirded properties.

This is easy to trigger if you make a couple new rules from the inspector.

Steps:
1) Inspect a page and select a div.
2) Create a new rule with the selector "body > div" or somthing specific.
3) Add "color: red" to that rule.
4) Create a new rule with a simple selector like "div".
5) Add "color: blue" to that rule.

Results:
The div text will be colored red. But the red property is crossed out and blue isn't.

Expected:
The blue property crossed out and the red property isn't. The rule order should be "body > div", "div".

See screenshot.

[Joseph Pecoraro]

This is a good point.  Adding selectors does not trigger a UI refresh immediately as I thought moving things around while the user is editing them might not be the best idea.  But you're absolutely right about incorrectly crossing out rules.

A simple solution would be to add a "Refresh" button.  You can simulate that by selecting another node in the tree and then selecting the original node again, forcing a UI refresh and things should be in order.  However, after giving this a test, the existing specificity sorting of that approach is questionable:
http://grab.by/3rF

I would expect "via inspector" and "inline styles" have something to do with this, but still more playing around produces results differing between the inspector's order and the page itself.