Proposal: RunAt.before_document_start

[Anton Bershanskiy]

Background

Extensions can run content scripts at different stages of content document lifecycle. Currently there are 3 values, "document_start", "document_end", "document_idle" which mean that the extension content script will run no earlier than a specific stage is reached. This works well for preventing content script from running too early, but does not help if content script explicitly needs to run as early as possible.

Reference

• MDN extensionTypes.RunAt
• Chrpmium docs chrome.extensionTypes

Problem/Motivation

Some content scripts need to shim a particular API in the content page. To do this, content script must reliably run before any other script on the page.

Other solutions considered

As of time of writing, there is no simple fool-proof way to run content script early. One can do the following to add a synchronous <script> tag somewhere in the document:

• use webRequest.StreamFilter to rewrite the document and insert a <script> tag which would execute synchronously.
• use proxy API to redirect request to a native HTTP proxy which would rewrite the response and add the <script> tag
• use blocking webRequest API to listen for onHeadersReceived and add HTTP response header Link to preload the script - very unreliable

Proposal

Add RunAt.before_document_start. This value means "execute content/user script as early as possible, before any other script on the page. May be, also introduce a new optional permission without a warning called scripting.before_document_start or scripting.synchroneous.

[Rob Wu]

There is consensus on NOT supporting before_document_start because the requested behavior is exactly what document_start is supposed to do (see meeting notes, pending review in #514).

If there are bugs with specific browser implementations, file bugs on the issue trackers of the specific browsers (and optionally: link them from here for visibility).