CSS rules inspector not showing rules when stylesheet has a data-uri sourcemap

RESOLVED DUPLICATE of bug 1255787

Status

()

Firefox
Developer Tools: CSS Rules Inspector
P1
normal
RESOLVED DUPLICATE of bug 1255787
2 years ago
2 years ago

People

(Reporter: Hiram J. Perez, Assigned: nchevobbe)

Tracking

({regression})

46 Branch
regression
Points:
---

Firefox Tracking Flags

(firefox45 unaffected, firefox46 wontfix, firefox47+ fixed, firefox48+ fixed)

Details

(Whiteboard: [btpp-fix-now])

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(6 attachments, 1 obsolete attachment)

(Reporter)

Description

2 years ago
Created attachment 8735971 [details]
comparission between firefox and chrome

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160328004018

Steps to reproduce:

Navigate to testcase: http://codepen.io/worg/full/GZvNEW
Open developer inspector
Select the h1 element [or any inside the iframe]


Actual results:

CSS inspector doesn't show any rules


Expected results:

CSS inspector should show rules for document [including browser styles]

Updated

2 years ago
Component: Untriaged → Developer Tools: CSS Rules Inspector
The test case provided defines a CSS source map with a data-uri, and it turns out the inspector doesn't know how to deal with those yet.

Here is the error:

Full Message: Component returned failure code: 0x804b000a (NS_ERROR_MALFORMED_URI) [nsIIOService.newURI]
Full Stack: JS frame :: resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/stylesheets.js :: dirname :: line 1187
JS frame :: resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/stylesheets.js :: StyleSheetActor<._setSourceMapRoot :: line 790
JS frame :: resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/stylesheets.js :: StyleSheetActor<._fetchSourceMap/</map< :: line 763
JS frame :: resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/Promise-backend.js :: Handler.prototype.process :: line 937
JS frame :: resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/Promise-backend.js :: this.PromiseWalker.walkerLoop :: line 816

When the StyleSheetActor tries to get the source map, it first gets the URL from the stylesheet content and runs it through a function called normalize which uses nsIIOService.newURI to resolve the URI.

We should add a check that prevents using normalize at all if the URI is a data-uri, since it doesn't need any resolving in that case.
It also doesn't need to be fetched from the network/cache, which is what the StyleSheetActor does after having normalized the URL.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P1
Whiteboard: [btpp-fix-now]
Summary: CSS inspector not showing rules → CSS rules inspector not showing rules when stylesheet has a data-uri sourcemap

Updated

2 years ago
Blocks: 1243736
status-firefox45: --- → unaffected
status-firefox46: --- → affected
status-firefox47: --- → affected
status-firefox48: --- → affected
tracking-firefox46: --- → ?
tracking-firefox47: --- → ?
tracking-firefox48: --- → ?
Keywords: regression
OS: Unspecified → All
Hardware: Unspecified → All
Version: 47 Branch → 46 Branch

Comment 2

2 years ago
Created attachment 8736011 [details]
index.html
(Assignee)

Updated

2 years ago
Assignee: nobody → chevobbe.nicolas
Recent regression, I can track this for 46 but it may be more realistic to fix it for 47.
tracking-firefox46: ? → +
tracking-firefox47: ? → +
tracking-firefox48: ? → +

Updated

2 years ago
status-firefox46: affected → wontfix
tracking-firefox46: + → ---
(Assignee)

Comment 4

2 years ago
Created attachment 8738106 [details]
Inline sourcemap in external css file
(Assignee)

Comment 5

2 years ago
Created attachment 8738107 [details]
inline sourcemap in <style> tag
(Assignee)

Comment 6

2 years ago
Created attachment 8738108 [details] [diff] [review]
Fix inline sourcemap issue in external css file

I followed your advices and test if the sourcemap file is a data-uri before normalize the URL.
I keep the fetch of the data-uri as it decode it, and I don't think it make a call to the network ? ( I looked at https://dxr.mozilla.org/mozilla-central/source/devtools/shared/sourcemap/source-map.js#588 , but I really don't  understand how webpack works ).

This patch didn't work on the original attached STR file, but it does work if the sourcemap is in an external CSS file ( as opposed to an inline <style> tag directly in the HTML file ).
So for an inline sourcemap in an inline style tag, I guess there is some kind of race condition that triggers this issue. I'll look at it this evening
Attachment #8738108 - Flags: feedback?(pbrosset)
(Assignee)

Updated

2 years ago
Attachment #8738108 - Flags: feedback?(pbrosset)
(Assignee)

Comment 7

2 years ago
Created attachment 8738981 [details]
MozReview Request: Bug 1260510 - Fix style editor when inline style tag has a data-uri sourcemap. r=pbro

Review commit: https://reviewboard.mozilla.org/r/44999/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/44999/
Attachment #8738981 - Flags: review?(pbrosset)
(Assignee)

Comment 8

2 years ago
Created attachment 8738984 [details]
Webpack sourcemap

Although the patch in review resolve the initial issue, there's still some odd things happening in https://bug1260510.bmoattachments.org/attachment.cgi?id=8736011 .
The decoded sourcemap ( as in https://dxr.mozilla.org/mozilla-central/source/devtools/server/actors/stylesheets.js#773 ) has 2 sources : the stylus one and also the generated CSS ( see the attachment ).
Because of this, when opening the style editor, there is 2 original sources.
Attachment #8738108 - Attachment is obsolete: true
As discussed today, let's file a separate bug for the style-editor not dealing well with source maps inside <style> tags.
And let's keep this bug to make sure the rule-view isn't empty for the test case given in comment 0.
The patch in comment 6 seemed correct for this problem.
(Assignee)

Updated

2 years ago
Attachment #8738981 - Flags: review?(pbrosset)
(Assignee)

Comment 10

2 years ago
I can't reproduce the initial bug anymore. I do see rules in the test case from comment 0. Could have this been resolved in another bug in the meantime ?

> As discussed today, let's file a separate bug for the style-editor not dealing well with source maps inside <style> tags.

Bug 1262919 filed for it
Flags: needinfo?(pbrosset)

Comment 11

2 years ago
Fix range:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d5d53a3b4e50b94cdf85d20690526e5a00d5b63e&tochange=494289c72ba3997183e7b5beaca3e0447ecaf96d

Probably fixed by:
Patrick Brosset — Bug 1255787 - Do not assume sourceMap appears only in external stylesheets; r=gl
I can't reproduce this bug in nightly either. I was wrong in comment 1, and indeed, as Loic said, bug 1255787 has fixed this too.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Flags: needinfo?(pbrosset)
Resolution: --- → DUPLICATE
Duplicate of bug: 1255787

Comment 13

2 years ago
Hello,

Should the fix already be in the current nightly build? Mine still produces the issue just as it did so far.

ed

Comment 14

2 years ago
(In reply to edimoldovan from comment #13)
> Hello,
> 
> Should the fix already be in the current nightly build? Mine still produces
> the issue just as it did so far.
> 
> ed

Be sure your Nightly is up-to-date. I tested the OP's testcase (or this one attached to the bug) and it's fixed.

Comment 15

2 years ago
True, that one works for me too. So not sure that I am talking about the same bug, I might need a little help with that. If you could try pulling the code from here: https://github.com/davezuko/react-redux-starter-kit doing an npm i then nppm start, you should the same issue in the inspector. I do at least.

Comment 16

2 years ago
Do you have a live testcase?

Comment 17

2 years ago
Not sure how to add it here, I'll try to describe it better then in my previous comment.

0. install latest node js if it is not installed yet
1. clone this repository: https://github.com/davezuko/react-redux-starter-kit
2. cd react-redux-starter-kit
3. npm install
4. npm start
5. go to http://localhost:3000/ in nightly
6. inspect the button labeled `Increment`
7. one should see styles in the inspector

Would this qualify for a live testcase?
(Assignee)

Comment 18

2 years ago
(In reply to edimoldovan from comment #17)
> Not sure how to add it here, I'll try to describe it better then in my
> previous comment.
> 
> 0. install latest node js if it is not installed yet
> 1. clone this repository: https://github.com/davezuko/react-redux-starter-kit
> 2. cd react-redux-starter-kit
> 3. npm install
> 4. npm start
> 5. go to http://localhost:3000/ in nightly
> 6. inspect the button labeled `Increment`
> 7. one should see styles in the inspector
> 
> Would this qualify for a live testcase?

Thank you for this test case, I was able to reproduce the bug. The consequences are the same, but the root cause is not. There is indeed a problem while fetching the sourcemap, but it is not because it's minified, it is because the CSS stylesheet location is something like `blob:http://localhost:3000/9f26b984-c837-f44f-bbe6-d0ccf05f8c6a` (I guess because it is created with createObjectURL), and it triggers an error in the `dirname` function when we call `Services.io.newURI(aPath, null, null))`.

I'm gonna file a bug for this, with a simpler STR, and will CC you on it.
(Assignee)

Comment 19

2 years ago
Bug 1263439 filed
(Reporter)

Comment 20

2 years ago
(In reply to Nicolas Chevobbe from comment #18)
> (In reply to edimoldovan from comment #17)
> > Not sure how to add it here, I'll try to describe it better then in my
> > previous comment.
> > 
> > 0. install latest node js if it is not installed yet
> > 1. clone this repository: https://github.com/davezuko/react-redux-starter-kit
> > 2. cd react-redux-starter-kit
> > 3. npm install
> > 4. npm start
> > 5. go to http://localhost:3000/ in nightly
> > 6. inspect the button labeled `Increment`
> > 7. one should see styles in the inspector
> > 
> > Would this qualify for a live testcase?
> 
> Thank you for this test case, I was able to reproduce the bug. The
> consequences are the same, but the root cause is not. There is indeed a
> problem while fetching the sourcemap, but it is not because it's minified,
> it is because the CSS stylesheet location is something like
> `blob:http://localhost:3000/9f26b984-c837-f44f-bbe6-d0ccf05f8c6a` (I guess
> because it is created with createObjectURL), and it triggers an error in the
> `dirname` function when we call `Services.io.newURI(aPath, null, null))`.
> 
> I'm gonna file a bug for this, with a simpler STR, and will CC you on it.

In fact the root cause may be the same… I'm using the same starter kit and that's what's failing for me, that's why I submitted this bug.
status-firefox47: affected → fixed
status-firefox48: affected → fixed
You need to log in before you can comment on or make changes to this bug.