My assumtion would be: - Font family starts to load - When Font family loaded and renderable I get an event - Then I can be sure that the font loaded and if I get the width of an inline element which has that font family, then I get the correct value Webkit fails to do this and fires the load event even when not able to render the font family yet. It happens mostly on IOS Safari when font family is not cache, but in simulated network enviroment, I can simulate it in Safari on OSX, Chrome on OSX and Chrome on Windows too. I have created a page to show this bug: http://smartslider3.com/bugs/webkit/fontfamily1/index.html It loads several Google Fonts with the Web Font Loader JavaScript library: https://github.com/typekit/webfontloader I tried it with document.fonts.ready, but it was even more inconsistent in non-simulated environment. If the output contains green "Fonts active + renderable" then everything was fine. If there is no green on the output or red appears, it means a fail. The desired output would be something like this (families might be in different order, depends on the network environment): Internet Explorer 11, Edge and Firefox produces the following result even in throttled network condition. 1495005090005 - Fonts active + renderable 1495005090005 - All family renderable 1495005090005 - Fonts active 1495005090004 - All family renderable 1495005090004 - Family Paytone One renderable 1495005089997 - Family Lato renderable 1495005089982 - Family Merriweather renderable 1495005089967 - Family Montserrat renderable 1495005089927 - Family Kaushan Script renderable 1495005089890 - Page loaded 1495005089854 - Font load started 1495005089854 - Window ready To be able to consistently reproduce the bug, you must throttle the network only on the host: fonts.gstatic.com (Charles proxy was great help in it.) Make sure to set up https proxy too if you are testing on the https version. For Safari/OSX testers: It is not enough to disable caches on develop tab. You must hit Empty caches to remove font families from the cache! It seems like disable cache has no effect on the font families. For IOS: when document load event fired, the default width with the system font changes so I have to update it to be able to compare to the soon-to-be-renderable font families. I think it is a bug too. Chrome - Failed output: Fons marked ready, but browser is not be able to render them yet. It takes more than 1 seconds for Family Kaushan Script to be able to render after it should be. 1495006708685 - All family renderable 1495006708685 - Family Kaushan Script renderable 1495006708078 - Family Lato renderable 1495006708050 - Family Paytone One renderable 1495006707802 - Family Montserrat renderable 1495006707578 - Fonts already marked active but NOT renderable 1495006707577 - Fonts active 1495006707529 - Family Merriweather renderable 1495006704563 - Page loaded 1495006704525 - Default width: 531 1495006704521 - Font load started 1495006704520 - Window ready Safari - OSX - Failed output: 1495007372801 - All family renderable 1495007372801 - Family Kaushan Script renderable 1495007372800 - Family Paytone One renderable 1495007372596 - Fonts already marked active but NOT renderable 1495007372594 - Fonts active 1495007372579 - Family Lato renderable 1495007372377 - Family Merriweather renderable 1495007371651 - Family Montserrat renderable 1495007369650 - Page loaded 1495007369543 - Default width: 531 1495007369539 - Font load started 1495007369538 - Window ready Safari - IOS - Failed output 1495006954937 - All family renderable 1495006954937 - Family Kaushan Script renderable 1495006954345 - Family Lato renderable 1495006954021 - Family Paytone One renderable 1495006953548 - Family Merriweather renderable 1495006952815 - Family Montserrat renderable 1495006952047 - Fonts already marked active but NOT renderable 1495006952041 - Fonts active 1495006952000 - Default width changed from the original value to: 918 1495006951990 - Page loaded 1495006951961 - Default width: 531 1495006951944 - Font load started 1495006951940 - Window ready
<rdar://problem/32249547>
I'm pretty sure I just fixed this in https://trac.webkit.org/changeset/216944/webkit. Can you try tomorrow's nightly build to see if it still happens?
Actually, I may not have read this site correctly. Let me investigate...
(In reply to Myles C. Maxfield from comment #3) > Actually, I may not have read this site correctly. Let me investigate... Thanks! Here is a screen capture in Chrome, but the same happens in Safari on IOS and OSX https://www.youtube.com/watch?v=lPejzEwBCh8&feature=youtu.be
I just tried with the nightly: 10.1 (12603.1.30.0.34, r217072) Here is the result, which is a fail I think. It seems like that it marks the fonts inactive if their was not able to load when the page load event fired. 1495191890700 - All family renderable 1495191890699 - Family Kaushan Script renderable 1495191890698 - Family Lato renderable 1495191890697 - Family Merriweather renderable 1495191890696 - Family Paytone One renderable 1495191888962 - Family Montserrat renderable 1495191880956 - Fonts inactive 1495191877876 - Page loaded 1495191877830 - Default width: 531 1495191877817 - Font load started 1495191877816 - Window ready In this case fonts were marked inactive and then loaded after a while. I think the load event of the page should fire if all of the resources loaded, I mean web font families too. I seems like the unload event does not wait for them to happen. Also I think the browser should fire some kind of event if able to correctly render a font family after the browser told that it can not render/load it. Also in this fail case document.fonts status shouldn't be loaded and the ready deferred shouldn't be resolved.
As suggested in the Chromium ticket, I have removed the Web Font Loader library and used only the native events. The problem gone in Chrome and fonts are marked active in the right time. Here is the native example: https://smartslider3.com/bugs/webkit/fontfamily1/index2.html Safari stills fails with this :(
We're also getting this issue with Webkit-based browsers. We confirmed Chrome and Safari on iOS and Safari (but not Chrome) on OS X. The following issue on Github contains a JSFiddle: https://github.com/typekit/webfontloader/issues/365#issuecomment-308395175
Hello fellas, Seems like the issue was fixed in Safari-11. Though the bug status is still new. Can some one help me by poiting to the chalgelist number that fixed it from Safari 10->11? FAQ's: Q.) WHy Can't I just upgrade to newer WebKit? Ans.) I am kind of stuck with WebKit 602 version as I am using a Qt's webkit port maintained on GitHub "https://github.com/qtwebkit/qtwebkit/wiki" Thanks in advance.
Myles C. Maxfield I see quite a few font-related submissions on changelog between safari 10 and 11. It would be great if you know what share the change list/s that might have fixed it in safari 11. Thanks
Seems like the issue was fixed in Safari-11.