- From: Boris Zbarsky via GitHub <sysbot+gh@w3.org>
- Date: Fri, 03 Feb 2017 14:36:25 +0000
- To: public-css-archive@w3.org
bzbarsky has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-font-loading] Is the relative ordering of steps in "switch the FontFaceSet to loaded" actually correct? == Consider a page that does this: var eventsFired = 0; var facesSeen = []; document.fonts.onloadingdone = document.fonts.onloadingerror = function(e) { ++eventsFired; facesSeen = facesSeen.concat(e.fontfaces); if (eventsFired == 2) { document.documentElement.textContent = "Font faces seen: " + facesSeen.length; } } var face = new FontFace("test", "url(http://example.com)"); face.load(); document.fonts.add(face); document.fonts.ready.then(function() { document.fonts.clear(); }); What should happen? Per https://drafts.csswg.org/css-font-loading/#switch-the-fontfaceset-to-loaded I believe the ordering will be: 1. Step 4 runs, fulfilling (async? It's not very clear) the ready promise. 2. Step 5 runs, queues a task. 3. The promise handlers get called, which calls `clear` on the `FontFaceSet`. This empties out the [[FailedFonts]] and [[LoadingFonts]] slots. 4. The task step 5 of the algorithm queued runs and fires the events. The lists are empty, so `facesSeen` should end up as an empty array in the testcase. But in practice, both Firefox and Chrome have a length-1 array. So presumably they're not implementing the spec. For example, maybe they're doing step 5 substeps 1-3 synchronously, not off a task... (well, I know that's what Firefox is doing, actually). That might be a more author-friendly behavior in this case. There should really be tests for this, if there aren't any, as well as tests for making sure that the promise handler runs before the events fire... Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1003 using your GitHub account
Received on Friday, 3 February 2017 14:36:33 UTC