Closed Bug 1291321 Opened 3 years ago Closed 3 years ago

[non-e10s] CSS inspector rules panel broken for links in Dev Edition when userContent.css is present

Categories

(DevTools :: Inspector, defect, P2)

49 Branch
defect

Tracking

(e10s-, firefox48 unaffected, firefox49 wontfix, firefox50 fixed, firefox51 fixed)

VERIFIED FIXED
Firefox 51
Tracking Status
e10s - ---
firefox48 --- unaffected
firefox49 --- wontfix
firefox50 --- fixed
firefox51 --- fixed

People

(Reporter: camden.narzt, Assigned: jdescottes)

References

Details

(Keywords: regression)

Attachments

(3 files, 1 obsolete file)

Attached file userContent.css (obsolete) —
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:49.0) Gecko/20100101 Firefox/49.0
Build ID: 20160801004002

Steps to reproduce:

Visit any webpage
right click a link
choose Inspect Element
make sure the rules tab is open in the inspector


Actual results:

No rules are shown (any other element I tried works).

Browser console had the following:
Exception { message: "Failed to open input source 'file:/…", result: 2152924148, name: "", filename: "resource://gre/modules/commonjs/too…", lineNumber: 499, columnNumber: 0, data: XPCWrappedNative_NoHelper, stack: "mainThreadFetch@resource://gre/modu…", location: XPCWrappedNative_NoHelper }protocol.js:907
Security Error: Content at https://bugzilla.mozilla.org/buglist.cgi?quicksearch=link%20css%20inspector&list_id=13145464 may not load or link to file:///Users/camdennarzt/Library/Application%20Support/Firefox/Profiles/nt92rxq8.dev-edition-default/chrome/userContent.css.
Protocol error (unknownError): Failed to open input source 'file:///Users/camdennarzt/Library/Application%20Support/Firefox/Profiles/nt92rxq8.dev-edition-default/chrome/userContent.css'utils.js:157
Protocol error (unknownError): Failed to open input source 'file:///Users/camdennarzt/Library/Application%20Support/Firefox/Profiles/nt92rxq8.dev-edition-default/chrome/userContent.css'rules.js:883


Expected results:

Rules pane should be populated.
1. Do you mean this issue happens only when you use the userContent.css?
2. Can you provide the example URL, and which link do you inspect?
3. Does this issue happen with safe-mode and clean profile?
Flags: needinfo?(camden.narzt)
1. Yes it only happens when I am using a userContent.css file
2. This page exhibits the behaviour (as well as every other page).
3.1 It does not happen in safe mode.
3.2 It does not happen with a fresh profile, even once I add a userContent.css file.

So I guess I'll blow away my profile, but that's such a pain.
Sounds like one of your extension is causing the issue.
can you disable all your extension first and enable them one by one, to see which extension causes it?
I also try to reproduce this on Mac OS X 10.10 with FF 49.0b1 and I can't reproduce. 

Cam please try what Tooru suggested.
Cam, did you try what Tooru suggested you in comment 3? Any luck? 
Until you ceme up with some information I will close this as resolved incomplete. Feel free to reopen it any time, also please provide the info requested.
Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → INCOMPLETE
No it hasn't started happening again after blowing away my profile.
I spoke too soon (or possibly jinxed myself) and the issue has returned (after updating to today's FF Dev Edition).

So I disabled each of my addons individually (restarting FF between each test) and the issue remained, I also disabled every addon at once (not safe mode, using about:addons) and the issue still remained.
Status: RESOLVED → UNCONFIRMED
Resolution: INCOMPLETE → ---
how about safe mode now?
In safe mode the issue doesn't happen.
have you restarted after disabling all add-ons ?
Yes, I restarted after disabling each add-on individually, and restarted after disabling all add-ons at once. Also obviously I had to restart to get into safe mode.
okay, can you open about:support and click "Copy raw data to clipboard", and save to text file, and upload it here?
Attached file ff_data.json
BTW is there a way to remove the "Multi-process staged rollout" extension? E10s is massively broken and it's annoying to have to keep disabling it.
Thanks.
I confirmed the issue.
This is non-e10s only.
Status: UNCONFIRMED → NEW
Component: Untriaged → Developer Tools: Inspector
Ever confirmed: true
Summary: CSS inspector rules panel broken for links in Dev Edition → [non-e10s] CSS inspector rules panel broken for links in Dev Edition when userContent.css is present
Yeah, the issue's not related to e10s, but I noticed in the data I uploaded that there's a hidden extension that opts me into e10s (repeatedly) and I'd love to kill that with fire.
Inspector bug triage (filter on CLIMBING SHOES).
Priority: -- → P2
Assignee: nobody → jdescottes
Status: NEW → ASSIGNED
First if all this only fails without e10s because userContent.css is not working at the moment when e10s is enabled (see Bug 1046166)

The regression comes from Bug 1282660. 
See https://dxr.mozilla.org/mozilla-central/rev/d5f20820c80514476f596090292a5d77c4b41e3b/devtools/server/actors/stylesheets.js#458

The stylesheet actor fails to download the userContent css file, which uses a file:// protocol. File protocol should be handled the same way as chrome and resource protocols here.
Blocks: 1282660
Attached file userContent.css
Attaching a simpler userContent.css, that will make the inspector blank for any element, and that contains a single selector & rule.

Basically if the inspected element matches any rule in userContent.css, the ruleview will be blank.

The initial userContent.css from the logger had rules impacting all <a> elements, which is why the bug was only triggered on links.
Attachment #8776982 - Attachment is obsolete: true
Gabriel: I simply added the file protocol to the chrome & resource one here, but I was wondering if it could make sense to whitelist http:// & https:// for using the document principal and use the system principal for all the others. 

Are there other protocols than http/https for which we want to use the document principal?
Flags: needinfo?(gl)
Comment on attachment 8787626 [details]
Bug 1291321 - Use system principal to download file:// stylesheets;

https://reviewboard.mozilla.org/r/76336/#review75352

::: devtools/server/actors/stylesheets.js:454
(Diff revision 1)
>        return promise.resolve(content);
>      }
>  
>      let options = {
>        loadFromCache: true,
> +

Don't need the extra new line.
Comment on attachment 8787626 [details]
Bug 1291321 - Use system principal to download file:// stylesheets;

https://reviewboard.mozilla.org/r/76336/#review75354
Attachment #8787626 - Flags: review?(gl) → review+
(In reply to Julian Descottes [:jdescottes] from comment #22)
> Gabriel: I simply added the file protocol to the chrome & resource one here,
> but I was wondering if it could make sense to whitelist http:// & https://
> for using the document principal and use the system principal for all the
> others. 
> 
> Are there other protocols than http/https for which we want to use the
> document principal?

This portion of the code is really a hack that I am not too comfortable with. At the moment, we use the system principal to handle chrome://, resource:// and now file://. While the changes to whitelist http:// and https:// to use the document principal and every other protocol uses the system principal makes sense to me, you should confirm with someone more familiar with the platform internals.
Flags: needinfo?(gl)
Thanks for the review, pushed to try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=0c6ed21bbcf7

(In reply to Gabriel Luong [:gl] (ΦωΦ) from comment #23)
> Comment on attachment 8787626 [details]
> Bug 1291321 - Use system principal to download file:// stylesheets;
> 
> https://reviewboard.mozilla.org/r/76336/#review75352
> 
> ::: devtools/server/actors/stylesheets.js:454
> (Diff revision 1)
> >        return promise.resolve(content);
> >      }
> >  
> >      let options = {
> >        loadFromCache: true,
> > +
> 
> Don't need the extra new line.

Fixed, thanks!
Pushed by jdescottes@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/3fe5546bc877
Use system principal to download file:// stylesheets;r=gl
https://hg.mozilla.org/mozilla-central/rev/3fe5546bc877
Status: ASSIGNED → RESOLVED
Closed: 3 years ago3 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 51
Duplicate of this bug: 1301682
Comment on attachment 8787626 [details]
Bug 1291321 - Use system principal to download file:// stylesheets;

Approval Request Comment
[Feature/regressing bug #]:Bug 1282660
[User impact if declined]: userContent.css can break the inspector's ruleview, and users cannot debug their CSS.  
[Describe test coverage new/current, TreeHerder]: no new test case. https://treeherder.mozilla.org/#/jobs?repo=try&revision=0c6ed21bbcf7
[Risks and why]: minor JS change: we are using a different principal to download stylesheets using the chrome:// and resource:// protocols, this patch simply makes the file:// protocol be treated in the same way
[String/UUID change made/needed]: N/A

Try on top of aurora: https://treeherder.mozilla.org/#/jobs?repo=try&revision=8824ba2e89cc
Attachment #8787626 - Flags: approval-mozilla-aurora?
Comment on attachment 8787626 [details]
Bug 1291321 - Use system principal to download file:// stylesheets;

fixes a recent regression, Aurora50+
Attachment #8787626 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Hello Cam, could you please verify this issue is fixed as expected on a latest Nightly build? Thanks!
Flags: needinfo?(camden.narzt)
A few things came of trying that:

https://nightly.mozilla.org/ is broken so getting Nightly right now is annoying (you have to edit the link to point to FF51.

Nightly seems to completely ignore the userContent.css file which isn't better than Dev-Edition as I can simply remove the usercontent.css file to achieve the same effect.

Also after starting Nightly, my kernel is now pegged at 100% cpu usage which is also really annoying.
(In reply to Cam from comment #14)
> BTW is there a way to remove the "Multi-process staged rollout" extension?
> E10s is massively broken and it's annoying to have to keep disabling it.

Have you filed any bugs on the e10s issues you've run into?
(In reply to Cam from comment #34)
> A few things came of trying that:
> 
> https://nightly.mozilla.org/ is broken so getting Nightly right now is
> annoying (you have to edit the link to point to FF51.
> 
> Nightly seems to completely ignore the userContent.css file which isn't
> better than Dev-Edition as I can simply remove the usercontent.css file to
> achieve the same effect.
> 

Did you make sure you were not using e10s? By default Nightly has e10s turned on, but you can open a new non-e10s window via "File > New non-e10s window"
Per Bug 1046166, userContent.css is disabled if e10s is on.
Right, that part where I have to disable e10s for things to work. :/

Anyway, yeah it seems fixed when I disable e10s.
Duplicate of this bug: 1314377
(In reply to Julian Descottes [:jdescottes] (PTO until 04-Nov) from comment #19)
> The regression comes from Bug 1282660. 

And FF49 is affected, the bugfix has landed only in FF50+.
As FF50 is almost released, I flag FF49 as wontfix.
Version: 50 Branch → 49 Branch
Status: RESOLVED → VERIFIED
Flags: needinfo?(camden.narzt)
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.