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

Reply via email to