729769 - Provide an API to block Windows

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, defect)

Description

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

In some cases, we end up in a situation where we have to synchronously do something slow (e.g. disk access) while running a script.  In these cases, it's better for responsiveness of the browser to avoid running scripts on a page while we "prefetch" the relevant data.  To do this, we need an API that allows thing to block script execution within a page.

The consumer we have in mind at the moment is localStorage, which could block pages from an origin that has localStorage data from running until that data is in-memory.

Comment 1

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

I think this already exists in the form of nsScriptLoader::AddExecuteBlocker.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

Couldn't we read the data localStorage needs to memory in a background thread. Start reading
when we initiate the request to such document/domain which we know has been using localStorage.

Comment 3

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

(In reply to Olli Pettay [:smaug] from comment #2)
> Couldn't we read the data localStorage needs to memory in a background
> thread. Start reading
> when we initiate the request to such document/domain which we know has been
> using localStorage.

That's the idea, but we want to block running script on the page until that reading completes.

Comment 4

[Boris Zbarsky [:bzbarsky]]

AddExecuteBlocker doesn't block event handlers and the like, right?  Just new <script> tags.

Comment 5

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

(In reply to Boris Zbarsky (:bz) from comment #4)
> AddExecuteBlocker doesn't block event handlers and the like, right?  Just
> new <script> tags.

Right.

Comment 6

[Henri Sivonen (:hsivonen)]

(In reply to Kyle Huey [:khuey] ([e-mail]) from comment #0)
> In some cases, we end up in a situation where we have to synchronously do
> something slow (e.g. disk access) while running a script.  In these cases,
> it's better for responsiveness of the browser to avoid running scripts on a
> page while we "prefetch" the relevant data.  To do this, we need an API that
> allows thing to block script execution within a page.

Rather, the block needs to scoped to a graph of pages reachable from each other via JS. Also, it needs to defer (enqueue) Necko events like OnStopRequest, too. Basically, we need per-page-constellation event queues and we need to audit all runnable dispatches to make them dispatch to the right queue.

Comment 7

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

After thinking about this more, I don't think we need to block "event handlers and the like".  Blocking at the first <script> tag should be enough for the localStorage optimizations.

So I think this is WFM.