I'm seeing the following errors on the browser console when trying to inspect the CSS rules affecting an element with the devtools 09:28:36.732 <unavailable> protocol.js:907 09:28:36.741 Protocol error (unknownError): Error: couldn't find start of the rule utils.js:160 09:28:36.743 Protocol error (unknownError): Error: couldn't find start of the rule rule-view.js:2030 The element is affected by some CSS rules generated via HTMLStyleElement.sheet.insertRule from a greasemonkey script. Name Firefox Version 45.0a1 Build ID 20151105030433

We recently (FF44) landed something called "as-authored" styles, which was a big rewrite of how the inspector and style-editor get information about stylesheets in the page. Now, styles appear exactly how they have been written in the downloaded resource. Which is way better than what we used to do (only display what Gecko had parsed). In order to get there, however, it was not possible to add support for styles added dynamically via the CSS object-model (CSSOM), like when using insertRule. Using the CSSOM will cause changes in the in-memory styles that can't be linked to the as-authored stylesheets. Tom knows a lot more than me about this, cc'ing him here. I think he had plans for ways to fix this, but that seemed complicated and CSSOM usage seemed low enough for it to be acceptable not to support it at first. Having said this, we should at least make sure the code doesn't break and degrade gracefully.

So the inspector isn't really showing what the rendering engine sees anymore, but information some earlier stage instead?

(In reply to The 8472 from comment #2) > So the inspector isn't really showing what the rendering engine sees > anymore, but information some earlier stage instead? Yeah, the rule view mostly works by examining the style sheets now. The computed view still gets all its information the "old" way. I'll make sure this works ok. See bug 1196250 for the full CSSOM plan for the rule view.

Comment on attachment 8688575 [details] [diff] [review] change getRelativeRuleLine to return 0 for line-less rules While investigating this bug I found that inDOMUtils.getRelativeRuleLine would return "funny" results, like 0xfffa, for rules created via CSSOM. I think it makes more sense to treat line number 0 specially, which is what this patch does.

Forgot to write a doc comment.

Comment on attachment 8688583 [details] [diff] [review] fall back to non-authored editing for CSSOM-created rules This has two parts. First, on the server side, if any rule has line==0, then it came from CSSOM, and we disable as-authored editing for the entire style sheet. Second, on the client side, getOriginalSourceStrings was not applying the same "line > 0" test that is used elsewhere in the rule view, leading to the location being "inline:-1" (something, btw, we've seen before and at least I didn't investigate at the time). (As an aside, I'm not sure how the line number of 0 changes to -1 on the client, but it's not really of any consequence, so I didn't track it down.) Note that due to races it is hard to test the getOriginalSourceStrings change. I could add a new event if you want.

Comment on attachment 8688583 [details] [diff] [review] fall back to non-authored editing for CSSOM-created rules Review of attachment 8688583 [details] [diff] [review]: ----------------------------------------------------------------- I agree with the approach to fall back to non-authored in case CSSOM was used. Just to confirm: this will disable authored-styles on a per-rule basis, right? Other rules from other stylesheets displayed in the rule-view will remain as authored? ::: devtools/server/actors/styles.js @@ +1165,5 @@ > // generated on the fly and the URI is not registered with the > // about: handler. > // https://bugzilla.mozilla.org/show_bug.cgi?id=935803#c37 > return !!(this._parentSheet && > + this.sheetActor.allRulesHaveSource() && Probably worth adding a comment here saying why we added this condition for (maybe add a reference to this bug too). ::: devtools/server/actors/stylesheets.js @@ +492,5 @@ > + try { > + rules = this.rawSheet.cssRules; > + } catch (e) { > + // sheet isn't loaded yet > + return true; What's the effect or returning true here when the sheet isn't loaded yet?

(In reply to Patrick Brosset [:pbrosset] [:pbro] from comment #9) > Just to confirm: this will disable authored-styles on a per-rule basis, > right? Other rules from other stylesheets displayed in the rule-view will > remain as authored? That's right. The effect is per-stylesheet. > Probably worth adding a comment here saying why we added this condition for > (maybe add a reference to this bug too). Will do. > ::: devtools/server/actors/stylesheets.js > @@ +492,5 @@ > > + try { > > + rules = this.rawSheet.cssRules; > > + } catch (e) { > > + // sheet isn't loaded yet > > + return true; > > What's the effect or returning true here when the sheet isn't loaded yet? In this case the style sheet can't have been modified via CSSOM. Probably either answer here is ok, but true seemed more correct to me. The effect is that this sheet should be considered a candidate for as-authored editing; but (1) this can change later and (2) it hardly matters, I think, because it seems to me that the actor can't return any rule from this sheet to the client, as the sheet isn't finished loading.

Rebased.

Rebased. Added comment per review.

https://hg.mozilla.org/integration/fx-team/rev/bbeb9431b88d https://hg.mozilla.org/integration/fx-team/rev/45708ae19e28

https://hg.mozilla.org/mozilla-central/rev/bbeb9431b88d https://hg.mozilla.org/mozilla-central/rev/45708ae19e28