FontFaceSet's load() method creates return promise in a global that doesn't match other browsers
Reported by
bzbar...@mit.edu,
Apr 12 2018
|
|||
Issue descriptionWhat steps will reproduce the problem? (1) Load the attached testcase. (2) Look at your console. What is the expected result? Probably "true", then "false" in the log. What happens instead? "false", then "true". Additional information: Firefox and Safari log "true", then "false". Edge doesn't implement document.fonts. In terms of the spec, https://drafts.csswg.org/css-font-loading/#dom-fontfaceset-load says: Let promise be a newly-created promise object. Without further qualification, this probably means "in the current Realm". Maybe. https://www.w3.org/2001/tag/doc/promises-guide is not super-clear about this. Of course maybe the spec needs to be clarified about creating in the relevant Realm and Firefox and Safari behavior changed...
,
Apr 12 2018
Per https://github.com/heycam/webidl/issues/135 and the navigator.getBattery() example at https://html.spec.whatwg.org/multipage/webappapis.html#realms-settings-objects-global-objects, I think relevant realm is more likely to be the correct choice?
,
Apr 12 2018
That getBattery() spec is ... weird. It aborts steps without returning anything from a method that's supposed to return stuff. I filed https://github.com/w3c/battery/issues/16 on that. But also, it's trying to return the same object on each call, and at that point it makes sense to create it in the relevant global, not whatever random current global you got called in. This case is creating a new promise on each call, though. So this is a somewhat different case...
,
Apr 12 2018
I thought the direction we were heading was to give uniform advice ("always use the relevant global"), and even codify that into a default in Web IDL, instead of asking spec authors to decide between relevant vs. current based on whether or not they're keeping the object around persistently.
,
Apr 12 2018
I thought so too, but that's not what the Promise bits of specs say right now, and it's not what UAs consistently implement... If that's the direction we're trying to go, we really need to get the spec end fixed. That makes it a lot easier to do things like write tests for the behavior and convince engineers to change their code.
,
Apr 13 2018
,
Apr 18 2018
|
|||
►
Sign in to add a comment |
|||
Comment 1 by bzbar...@mit.edu
, Apr 12 2018