Closed
Bug 1260510
Opened 8 years ago
Closed 8 years ago
CSS rules inspector not showing rules when stylesheet has a data-uri sourcemap
Categories
(DevTools :: Inspector: Rules, defect, P1)
Tracking
(firefox45 unaffected, firefox46 wontfix, firefox47+ fixed, firefox48+ fixed)
RESOLVED
DUPLICATE
of bug 1255787
People
(Reporter: worg, Assigned: nchevobbe)
References
Details
(Keywords: regression, Whiteboard: [btpp-fix-now])
Attachments
(6 files, 1 obsolete file)
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•8 years ago
|
Component: Untriaged → Developer Tools: CSS Rules Inspector
Comment 1•8 years ago
|
||
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]
Updated•8 years ago
|
Summary: CSS inspector not showing rules → CSS rules inspector not showing rules when stylesheet has a data-uri sourcemap
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
Assignee | ||
Updated•8 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.
![]() |
||
Updated•8 years ago
|
tracking-firefox46:
+ → ---
Assignee | ||
Comment 4•8 years ago
|
||
Assignee | ||
Comment 5•8 years ago
|
||
Assignee | ||
Comment 6•8 years ago
|
||
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•8 years ago
|
Attachment #8738108 -
Flags: feedback?(pbrosset)
Assignee | ||
Comment 7•8 years ago
|
||
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•8 years ago
|
||
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
Comment 9•8 years ago
|
||
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•8 years ago
|
Attachment #8738981 -
Flags: review?(pbrosset)
Assignee | ||
Comment 10•8 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•8 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
Comment 12•8 years ago
|
||
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
Closed: 8 years ago
Flags: needinfo?(pbrosset)
Resolution: --- → DUPLICATE
Comment 13•8 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•8 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•8 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•8 years ago
|
||
Do you have a live testcase?
Comment 17•8 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•8 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•8 years ago
|
||
Bug 1263439 filed
Reporter | ||
Comment 20•8 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.
Updated•8 years ago
|
Updated•5 years ago
|
Product: Firefox → DevTools
You need to log in
before you can comment on or make changes to this bug.
Description
•