This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/ Multipage: http://www.whatwg.org/C#processing-model-4 Complete: http://www.whatwg.org/c#processing-model-4 Referrer: Comment: Note on synchronous section order seems incorrect Posted from: 113.23.85.48 User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.68 Safari/537.36 OPR/19.0.1326.26 (Edition Next)
"A synchronous section never mutates the DOM, runs any script, or has any side-effects detectable from another synchronous section, and thus synchronous sections can be run in any order, and cannot spin the event loop." This isn't true for the resource selection algorithm and the "When a media element is removed from a Document" algorithm, for example: <!DOCTYPE html> <video></video> <script> var v = document.querySelector('video'); v.play(); v.appendChild(document.createElement('source')); // invokes resource selection, sets networksState NETWORK_NO_SOURCE v.removeChild(v.firstChild); // so that resource selection will fail and go back to NETWORK_EMPTY in the sync section v.parentNode.removeChild(v); // invoke the removal algorithm, which checks networkState </script> <script> w(v.paused); </script> Both algorithms await a stable state and both do things with networkState. If the resource selection sync section runs first then the element removal sync section will see NETWORK_EMPTY and abort. If the removal sync section runs first it will call pause(), which clearly has side-effects.
(In reply to Philip Jägenstedt from comment #1) > v.play(); > v.appendChild(document.createElement('source')); // invokes resource > selection, sets networksState NETWORK_NO_SOURCE > v.removeChild(v.firstChild); // so that resource selection will fail and go > back to NETWORK_EMPTY in the sync section Oops, play() already invokes resource selection, so the appendChild/removeChild aren't needed to trigger the problem.
Ok, I tried to make this better. But I may have broken it even further... let me know if the new text is worse...
Checked in as WHATWG revision r8447. Check-in comment: Make the automatic pausing when you take a <video> out of a Document happen regardless of whether it's still loading or not. http://html5.org/tools/web-apps-tracker?from=8446&to=8447
(In reply to Ian 'Hixie' Hickson from comment #3) > Ok, I tried to make this better. But I may have broken it even further... > let me know if the new text is worse... The fix looks good to me, as the internal pause steps only touches the paused attribute and none of the other synchronous sections look at it, AFAICT.