<rdar://problem/65560550> and https://bugs.webkit.org/show_bug.cgi?id=215435
Reviewed by Myles C. Maxfield.
Source/WebCore:
Second take at this.
Myles took the first swipe at this, but a conflict with SuspendableTimer caused issues
in the form of layout test asserts with
http/tests/security/navigate-when-restoring-cached-page.html
His original ChangeLog entry:
Font loads are coalesced using a zero-delay timer. However, that zero-delay timer
can fire while the page is in the middle of a navigation, which will cause the font
loads to fail. Then, the second page can request those same fonts, which are marked
as failed, and as such will never actually load/use the desired web font.
This patch just stops the zero-delay timer during navigations, and resumes it
when resuming the document. This means:
1. The second page in the above story will not see that the font has failed, or
even started, and will then re-request the font and load it successfully
2. If the user goes "back" to the previous page, the zero-delay timer is restarted,
the CachedFont realizes it's already succeeded, and the previous page is rendered
as expected.
Test: fast/loader/font-load-timer.html
---
Now the explanation of the failure it caused:
The font loading timer was a SuspendableTimer, which is an ActiveDOMObject.
An ActiveDOMObject was used to make sure the delayed font loads play well with the
page cache, which is still necessary.
But we also still need to suspend the timer manually when "stopLoading()" is called,
which doesn't play well with ActiveDOMObject's automatic suspend/resume.
My solution:
- Make the timer "just a normal timer"
- Make CSSFontSelector itself the ActiveDOMObject
- Let DocumentLoader explicitly pause the font load timer
- Rely on ActiveDOMObject to resume the timer
These keep the bug fixed and resolve the layout test ASSERT seen with
http/tests/security/navigate-when-restoring-cached-page.html
* css/CSSFontSelector.cpp:
(WebCore::CSSFontSelector::CSSFontSelector):
(WebCore::CSSFontSelector::clearDocument):
(WebCore::CSSFontSelector::beginLoadingFontSoon):
(WebCore::CSSFontSelector::suspendFontLoadingTimer):
(WebCore::CSSFontSelector::fontLoadingTimerFired):
(WebCore::CSSFontSelector::stop):
(WebCore::CSSFontSelector::suspend):
(WebCore::CSSFontSelector::resume):
(WebCore::CSSFontSelector::beginLoadTimerFired): Deleted.
* css/CSSFontSelector.h:
* loader/DocumentLoader.cpp:
(WebCore::DocumentLoader::stopLoading):
LayoutTests:
1) The page has some content that has “font-family: WebFont” but there are no @font-face blocks on the page
2) In script, after the page has loaded, add an @font-face rule to the page with “font-family: WebFont” and some valid font URL
3) Synchronously, within the same turn of the run loop, trigger a synchronous layout of the element (using offsetWidth or something). This will add the font to the 0-delay time work list.
4) Synchronously, within the same turn of the run loop, navigate to a second page that doesn’t use the web font.
5) The second page waits some small-but-positive amount of time. This will cause the 0-delay timer to fire, but because the page is in the middle of navigating, the font load should fail.
6) The second page adds the same @font-face rule to itself using script. This should pull the same (failed) CachedResource object out of the memory cache.
7) Use the CSS Font Loading API to wait for the font load to complete
8) Make sure that the font is used on the second page (as a reference test). Today, the second page’s font load will fail because it pulled the failed font out of the memory cache. The test makes sure the second page’s font load succeeds.
* fast/loader/font-load-timer-expected.html: Added.
* fast/loader/font-load-timer.html: Added.
* fast/loader/resources/font-load-timer-navigation-destination.html: Added.
Canonical link: https://commits.webkit.org/228618@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@266148 268f45cc-cd09-0410-ab3c-d52691b4dbfc
911fb39b7f
