iOS Safari 10 fixes doesn't apply to WebViews
fangel opened this issue · 2 comments
We have recently rolled out a new font-loading strategy that relies on FontFaceObserver, and we realised that when our pages was loaded inside a web-view on iOS, then our fonts wouldn't load very consistently.
An example of a web-view would be either the Chrome or Firefox for iOS browsers - or the Facebook-app (which probably has a much bigger install-base that the other two). These apps are (as I understand it) basically a nice wrapper around WKWebView which is the Safari-in-a-box component you can use when building iOS apps. (The other alternative is UIWebView which is a not-quite-Safari-in-a-box because it doesn't have JS optimisations etc enabled).
After a while, I managed to track down this inconsistency to FontFaceObserver itself.
As of #86, a check was introduced to disregard the native font-loading API in Safari 10. This check is based on a UA-check against "Version/10" so that it only applies to Safari 10. However, the UA of web-views does not include "Version/10", but instead whatever the app chose (I.e. Firefox has FxiOS/6.1).
This means that whenever the page is loaded inside a web-view (like the Firefox for iOS browser), then FontFaceObserver actually tries to rely on the native-API that is faulty - and since those doesn't work as intended, FontFaceObserver doesn't work as intended.
I'm not sure what the best approach is, but my idea would be to change the UA reg.exp. into something that checks the AppleWebKit version (602.4.6 seems to be the one in Safari 10 GM).
Allegedly the latest versions of Safari (Tech Preview and Nightly) has fixed the native-API, and based on the current nightly, they have AppleWebKit version 604.1.7+.
The release-notes on TP 19 has a release-note that hints towards fixing the bugs, and to the best of my ability that was AppleWebKit 603.1.14 (https://webkit.org/blog/7093/release-notes-for-safari-technology-preview-19/).
So maybe the test should be made into a test similar to the one in hasWebKitFallbackBug where it checks for AppleWebKit version >=538.11, and then use something like >=603.1.14 or >=604?
I don't mind creating a PR for this approach if you agree that it is a reasonable approach.
Kind regards
Morten
Ugh (not aimed at you, but the situation). Thanks for writing that up. I didn't think about web views when writing that workaround. Looking at the WebKit version seems like the best way forward. A pull request would be most appreciated. Thanks a lot!
I merged this in, thanks again. I'll release a new version.