https://bugzilla.wikimedia.org/show_bug.cgi?id=47457
--- Comment #53 from Krinkle <[email protected]> --- (In reply to comment #52) > Krinkle -2ed my changeset, pointing to some unspecified "relevant" bug that > is not this one. Fine, he can fix it. The bug title changed and there's over 50 comments. I didn't find the comment I was referring to so I presumed it was a different bug. However it looks like it was this bug indeed. Here's the comment I was referring to: (In reply to comment #35) > There's one use case for the blocking (document.write) code path. Namely the > top loading queue. > > Though I suppose it is harmless there as there is no way the document will be > ready there. > > My intention is to refactor mw.loader to default to async and only use the > synchronous method when explicitly told so (no more magic switching based on > document-ready). Earlier on April 25 TheDJ mentioned this bug to me and the above is how I recommended fixing it. Later James assigned the bug, but while I implemented the above locally already, testing locally in Firefox did not seem to fix the bug. The change Ic3d0c937268d0943d2 implements a similar approach, though by using an additional global mw.loader state and <script> tag to set it instead of simply passing it as an argument (like it already does for the wgResourceLoaderExperimentalAsyncLoading feature flag). Aside from it being a slightly less ideal approach, as I mentioned, it didn't fix it for me (though it is a race conditional, so it might fix it). Also note that even though it does not fix it in for the masses because our html output is statically cached for 30 days. I'' re-open the change and amend it to work the way I proposed it 4 days ago in the comment quoted above. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
