On Monday, July 6, 2015 at 12:48:33 PM UTC-7, smaug wrote: > I don't know what "have a MO set on the document during readyState=loading" > actually means.
Document has three loading states - loading, interactive, complete[0]. I'm initializing MO during loading stage, so that I have a chance to mutate elements before it gets to interactive stage. > MutationObserver callback is called at the end of microtask, so end of > outermost script execution or end of a task in general. I don't think that's what is happening right now. I have an extended example at the end of this post. > And MutationObserver has nothing to do with DOMContentLoaded. I understand that. But MO fired synchronously in document.readyState=='loading' should compete it's callback before DOMContentLoaded I believe. > I don't see any <link> elements in your example Yeah, I overminimized my testcase. Below is a better one :) > Oh, you want to ensure MutationObservers are called before some script is > executed? That is indeed still a bug, Bug 789315. Not necessarily, although that would probably fix my problem. I expect that if I have MO set during the time when Parser is parsing HTML, then MO's callback should be called when the element is injected into DOM and that means before DOMContentLoaded is called. It just seems logical to not call DOMContentLoaded (and not fire deferred scripts in result) until MO callback is executed on elements injected into DOM by Parser. I believe that it's not the case right now. The proper testcase: http://labs.braniecki.net/mo/ Around 80% of time my console looks like this: 1) mo start mo.js:3:3 2) mo onMutations mo.js:16:5 3) setting ready on the element mo.js:30:7 4) main.js starts main.js:1:1 5) Promise { <state>: "fulfilled", <value>: Response } Which seems to be the right order. 1/2/3 are synchronously launched, 3 is fired when Parser injects link into DOM, and then DOMContentLoaded triggers execution of deferred script in 4) and in 5) we capture link.ready as a promise. Around 20% of time my console looks like this: 1) mo start mo.js:3:3 2) main.js starts main.js:1:1 3) undefined main.js:5:1 4) mo onMutations mo.js:16:5 5) setting ready on the element which seems to be wrong. MutationObserver starts in 1, but then DOMContentLoaded triggers deferred main.js in 2 before MO callback is executed. With this behavior it seems that there's no way to ensure that deferred scripts operate on DOM already altered by synchronously executed MO callbacks, which is what enables us to prototype and shim DOM related API's. Does my logic make any sense? zb. [0] https://developer.mozilla.org/en-US/docs/Web/API/Document/readyState _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform