User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.46 Safari/537.36 Steps to reproduce: 1) Create FontFace instance 2) Add it to the document.fonts of an iframe in the current page jsfiddle: https://jsfiddle.net/ew0nsp96/1/ Actual results: Exception is throw. NotSupportedError: Operation is not supported Expected results: FontFace is successfully added This works in Chrome. A workaround creating FontFace instances for the iframe via "iframe.contentWindow.FontFace". https://jsfiddle.net/uusfn02c/3/ This approach fails in Chrome.
The spec for the font loading API talks a lot about "the document"; it seems to be assuming that all the objects are associated with the same document... I raised a spec issue to clarify how this is supposed to actually behave: https://lists.w3.org/Archives/Public/www-style/2015Sep/0010.html
There is now an issue in the spec to clarify which document is meant when one is referred to. I have patches in bug 1163877 that allow a FontFace to be inserted into multiple FontFaceSets, which I believe Tab intended to be allowed, though John was skeptical of the value of. Still there's no particular reason, from the spec's point of view, to disallow this. (For CSS-connected FontFace objects we're already required to throw if trying to insert it into another FontFaceSet). As a byproduct those patches allow FontFaces to be created in one window and inserted into the FontFaceSet of another. I'm inclined to just take them. WDYT John?
Flags: needinfo?(cam) → needinfo?(jdaggett)
I'll go through the patches on that bug.
Status: UNCONFIRMED → NEW
Component: DOM: Core & HTML → DOM: CSS Object Model
Depends on: 1163877
Ever confirmed: true
Fixed by the patches in bug 1163877.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
2 years ago
platform-rel: --- → +
You need to log in before you can comment on or make changes to this bug.