Teach SharedStyleSheetCache (or so) to share inline styles
Categories
(Core :: CSS Parsing and Computation, enhancement, P3)
Tracking
()
People
(Reporter: emilio, Assigned: emilio)
References
(Blocks 1 open bug)
Details
(Keywords: leave-open)
Attachments
(5 files)
See bug 1928800 for something that would benefit for this (but in general maybe we can do it regardless).
Tricky thing is that the base URI is different for different pages, so we need to check for that, or for the sheet not having relative URIs...
Assignee | ||
Comment 1•1 month ago
|
||
Assignee | ||
Updated•1 month ago
|
Assignee | ||
Comment 2•1 month ago
|
||
Assignee | ||
Comment 3•1 month ago
|
||
(These are numbers without the base URI cache, assuming they're roughly comparable)
Assignee | ||
Updated•1 month ago
|
Assignee | ||
Comment 4•26 days ago
|
||
So I think we should do this because bug 1928800 and co look a lot better with this.
I found a few legit bugs that needed fixing are are easy to fix. I found one which is just rather annoying to fix tho, and it's (mostly) pre-existing.
The test is security/manager/ssl/tests/mochitest/mixedcontent/test_cssBefore1.html
(well, and test_cssContent1.html, but basically the same). It tests that the mixed content flag show before and after navigation.
The issue is that now the sheet is cached, which means that we don't do the second image request on navigation. This is expected, but that doesn't update the UI state. The issue is already present there if you use a <link rel=stylesheet>
rather than an inline stylesheet...
Tom, Freddy, how much do we care about mixed-content warnings nowadays? Should I dig into how to potentially fix this? It's.. not easy, because we somewhat aggressively cache these requests. I can of course do something hacky like "if there are http uris, don't put the sheet in the cache", but that's just lame.
Comment 5•26 days ago
|
||
I think with the work on HTTPS-First and Only we care about the mixed content blocker a lot less. If it's already broken for external stylesheets and blocking performance work I wouldn't bother.
Assignee | ||
Comment 7•26 days ago
|
||
Network override needs this already for <link>, the test was using
@import to bypass the usual caching.
browser_resources_css_messages.js needs to clear the cache as well now
that reloading might not reparse the stylesheet.
Updated•26 days ago
|
Assignee | ||
Comment 8•26 days ago
|
||
As per the comments in the bug, this is already broken for <link
rel=stylesheet>. The issue is that we don't re-trigger the image request
now, as we cache the whole stylesheet.
An alternative would be to use a CSS variable or so to bypass the style
resource caching, lmk if you want me to do that instead.
Assignee | ||
Comment 9•26 days ago
|
||
Without this tests like layout/reftests/svg/as-image/context-fill-*.html
fail, because they test both pref-on and pref-off on the same
stylesheet.
Assignee | ||
Comment 10•26 days ago
|
||
Two tweaks:
-
Use variables for tests that rely on background images triggering a
load that had otherwise been cached already.
printpreview_images_sw.html use serviceworkers, and
visited_image_loading_frame.html uses a server script to watch the
loads. -
Add a null-check for test_rules_out_of_sheets. Now we hit this early
return in appendRule1. The no-sheet case was what this test was
intending to hit anyways, so it was just by chance it didn't before
(because the sheet was kept alive by Loader::mInlineSheets, but with
the new cache we shallow-clone it).
Updated•26 days ago
|
Comment 11•25 days ago
|
||
Assignee | ||
Updated•25 days ago
|
Comment 12•25 days ago
|
||
Comment 13•25 days ago
|
||
bugherder |
Description
•