See Bug 1320673 comment #6 (In reply to reyad.attiyat from Bug 1320673 comment #6) > I was able to reproduce this issue by creating an css stylesheet with a very > large background-image data url. I experienced this issue when using webpack > url-loader which does not have a default limit and would generate data urls > for all images, even very large ones. > > I will attach a sample file.

You can open https://bugzilla.mozilla.org/attachment.cgi?id=8925107 to reproduce the issue (initial attachment from reyad.attiyad in Bug 1320673)

Thanks for filing. This is a problem with our lexer (/devtools/shared/css/lexer.js). Specifically, the test case fails here: http://searchfox.org/mozilla-central/rev/5a60492a53667fc61a62af1847d005a210b7a4f6/devtools/shared/css/lexer.js#691 With the following error: RangeError: too many arguments provided for a function call

Looks like on Firefox, the maximum number of arguments you can pass a javascript function is 500000. However the data-uri is being split in several millions of parts and that line of code therefor fails.

This is more complex. Fixing the lone mentioned previously is easy, it can be changed to something like this: > let codes = stringToCodes(this.mBuffer.slice(this.mOffset, n)); > for (let i = 0; i < codes.length; i++) { > aText.push(codes[i]); > } (which, btw, seems faster than array.concat()). But then, another spot needs to be fixed: http://searchfox.org/mozilla-central/rev/5a60492a53667fc61a62af1847d005a210b7a4f6/devtools/shared/css/lexer.js#433 > String.fromCharCode.apply(null, token.mIdent); which fails for the same reason. This one can be changed to: > let text = ""; > for (let i = 0; i < token.mIdent.length; i++) { > text += String.fromCharCode(token.mIdent[i]); > } This makes it work, but then the rule-view is very very very slow, and in fact quite unusable. There are 2 reasons to this I think: 1. it's very slow to even get the data to the client. It is parsed once on the server and that takes time, then transmitted, and then parsed once again on the client. 2. the DOM create on the client for this is quite huge and makes things like scrolling or resizing just impossible. I think that part is the same as bug 1244661. So, in this bug, we should focus on improving the parsing and transmission time.

I came across this and it might be worth mentioning we had a similar issue on Activity Stream. This is how we got around it https://github.com/mozilla/activity-stream/blob/df09fdfff0164993c9173f0972a6b7c2360810bf/system-addon/lib/Screenshots.jsm#L29-L41 I'll try a patch when I get more time but in the meantime wanted to share our fix.

Hi, just came across this behavior, but I see you already know. Posting to get to CC. Rules in inspector are empty if I use big base64 encoded background-image, 307kb image works, 404kb image does not. Chrome and IE11 are not experiencing this behavior with half megabyte image (sizes before conversion to base64). I even tried 4K bitmap image (aprox. 24MB), which works in Chrome inspector, but it crashes IE11 tab when I try to access the inspector. By the way, I had no idea, that the Firefox JavaScript engine has 500000 function arguments limit. Nice to know, I am learning something every day.

Pushed by jdescottes@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/bc761997c4aa [devtools] Fix ruleview with large base64 background image r=nchevobbe https://hg.mozilla.org/integration/autoland/rev/27c8db8efbc2 [devtools] Truncate extremely long text nodes in the ruleview r=nchevobbe