At what point do web browsers unblock interactive events exactly?

Question

The readystatechange event has a state named “interactive”, which sounds like that the browser is blocking interactive events beforehand. Is that standardized somewhere? What are the details?

I mean, if the browser would not defer/postpone or block those events, then there would always be a race condition with Javascript attaching event handlers, unless Javascript is mixed with HTML (either with attributes like onclick or Javascript generates the whole element itself).

_{Example: A browser loading a huge page might already render parts of the DOM visible to the user (subject to changes, of course) without having even finished downloading the HTML. What if the user clicks something? Will that event be ignored, delivered now or executed later? I hope it will deliver later with the event object being generated and routed at the time of unblocking, not at the click time.—Ignoring is fine, too.}

user_3702797 · Answer

which sounds like that the browser is blocking interactive events beforehand

No it doesn't sound like that, interactive here only means we can interact with the Document safely: its markup has been completely parsed and its DOM is fully ready, it is now interactive.

No link whatsoever with UI-events, an User-Agent could implement that part of the specs without handling any UI-event (think headless browsers).

Before the Document is even created, its browserContext will already have its agent set, and its event-loop running.
So even before the document is created, the event loop could receive UI-events, _{though I don't think there is anything outside of the Document where it could be dispatched from}.

As to when these events will get dispatched, I think there is some interop issues here, but theoretically, the HTML parsing should be synchronous and these events should get dispatched asynchronously.
_{Not too sure about UI-events, but at least some network events like load were dispatched synchronously before the full parsing in Webkit browsers for years}

user_825924 · Answer

Are events blocked in the beginning? No. The page is as “interactive” as it could be even during main page load, so I do consider the interactive readyState a misnomer indeed. Events will be fired “as usual” and can pile up if the handler(s) take too much time, also as usual.

Network handling is probably done concurrent to Javascript execution¹, but HTML parsing is not. The advancement in HTML parsing is almost like a task on the Javascript run queue: either HTML is parsed, or Javascript is executed and if Javascript does not yield, no further HTML will be parsed.

Priorities are handled differently in Chrome and Firefox: e.g. Chrome will consistently schedule event handling before further HTML parsing, while Firefox often (but not always) seems to parse buffered HTML before scheduling the next event handler.

And all this happens while document.readyState is on loading.—I observed this with the browser console and a hand-made server slowly dishing out simple HTML with inline script parts before entering a loop where it sends

... elements after a sleep, i.e. it never finished serving.

Summary: readyState === 'interactive' is nothing more than “main page finished parsing.”

_{¹additional restrictions apply as usual: e.g. immediate}

At what point do web browsers unblock interactive events exactly?

2 Answers