Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Font families might not really loaded in WebKit based browsers in specific networks conditions #365

Open
nextend opened this issue May 17, 2017 · 5 comments · May be fixed by #402
Open

Comments

@nextend
Copy link

nextend commented May 17, 2017

Related bug report in WebKit bug tracker: https://bugs.webkit.org/show_bug.cgi?id=172210

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.
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
@nextend
Copy link
Author

nextend commented May 17, 2017

#353 can be the same issue

@nextend
Copy link
Author

nextend commented May 29, 2017

With the native font load api, my example works fine in Chrome, so there is an issue in this library. Safari still fails with the native font load api.

https://smartslider3.com/bugs/webkit/fontfamily1/index2.html

@teebow
Copy link

teebow commented Jun 7, 2017

@nextend did you find any workaround for this ?

@nextend
Copy link
Author

nextend commented Jun 7, 2017

No. Chrome seems fine with native font loader api, so there is a bug in Web font loader.

For Safari, I think it is a bug in Webkit and not in thus library.

@pavloKozlov
Copy link

pavloKozlov commented Jun 14, 2017

I faced with the same issue.
May be jsfiddle helps: https://jsfiddle.net/PavelKozlov/o812c9fk/3/

This bug reproduces in Safari (MacOS X, iOS) and Chrome (iOS).
Basically, only webkit engine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
3 participants