Summary: | Mixing Content Blocking of fonts and display:none rules causes battery drain | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Myles C. Maxfield <mmaxfield> | ||||||||||||||
Component: | New Bugs | Assignee: | Myles C. Maxfield <mmaxfield> | ||||||||||||||
Status: | RESOLVED FIXED | ||||||||||||||||
Severity: | Normal | CC: | buildbot, cdumez, commit-queue, esprehn+autocc, kangil.han, rniwa, webkit-bug-importer | ||||||||||||||
Priority: | P2 | Keywords: | InRadar | ||||||||||||||
Version: | WebKit Nightly Build | ||||||||||||||||
Hardware: | Unspecified | ||||||||||||||||
OS: | Unspecified | ||||||||||||||||
Attachments: |
|
Description
Myles C. Maxfield
2016-01-12 17:52:50 PST
Created attachment 268835 [details]
Patch
Comment on attachment 268835 [details] Patch Attachment 268835 [details] did not pass mac-ews (mac): Output: http://webkit-queues.webkit.org/results/684709 New failing tests: http/tests/security/contentSecurityPolicy/user-style-sheet-font-crasher.html Created attachment 268843 [details]
Archive of layout-test-results from ews100 for mac-yosemite
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews100 Port: mac-yosemite Platform: Mac OS X 10.10.5
Comment on attachment 268835 [details] Patch Attachment 268835 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.webkit.org/results/684713 New failing tests: http/tests/security/contentSecurityPolicy/user-style-sheet-font-crasher.html Created attachment 268845 [details]
Archive of layout-test-results from ews107 for mac-yosemite-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews107 Port: mac-yosemite-wk2 Platform: Mac OS X 10.10.5
Comment on attachment 268835 [details] Patch Attachment 268835 [details] did not pass mac-debug-ews (mac): Output: http://webkit-queues.webkit.org/results/684705 New failing tests: http/tests/security/contentSecurityPolicy/user-style-sheet-font-crasher.html Created attachment 268847 [details]
Archive of layout-test-results from ews114 for mac-yosemite
The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews114 Port: mac-yosemite Platform: Mac OS X 10.10.5
Created attachment 268848 [details]
Patch
Yeah; it's as I suspected; this patch doesn't actually fix the bug. Any time you clear the style resolver, a layout will occur, which means the font will be used again, which means we will go through content blockers, which means we may clear the style resolver again. (In reply to comment #10) > Yeah; it's as I suspected; this patch doesn't actually fix the bug. Any time > you clear the style resolver, a layout will occur, which means the font will > be used again, which means we will go through content blockers, which means > we may clear the style resolver again. It looks like I'll need some bit of state saying "this font was blocked; don't try again." However, this means that I'll need some way of knowing when content blocker rules change (to clear the state). (In reply to comment #11) > (In reply to comment #10) > > Yeah; it's as I suspected; this patch doesn't actually fix the bug. Any time > > you clear the style resolver, a layout will occur, which means the font will > > be used again, which means we will go through content blockers, which means > > we may clear the style resolver again. > > It looks like I'll need some bit of state saying "this font was blocked; > don't try again." However, this means that I'll need some way of knowing > when content blocker rules change (to clear the state). Maybe the key here is that layout triggers the download, rather than setting a src attribute or something like that (for an image). Created attachment 269021 [details]
Patch
Comment on attachment 269021 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=269021&action=review > Source/WebCore/ChangeLog:8 > + If we have applied a rule before, don't apply it again (thereby avoiding a relayout). If we have applied a rule before and we are not applying it again, don't resolve the style again. The problem wasn't that we were applying it again, the problem was that we were doing another style resolution when we weren't changing anything, which often led to infinite loops. Committed r195088: <http://trac.webkit.org/changeset/195088> Follow-up patch at http://trac.webkit.org/changeset/195089 Committed r195161: <http://trac.webkit.org/changeset/195161> |