Proposal: RunAt.before_document_start
bershanskiy opened this issue · comments
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
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 foronHeadersReceived
and add HTTP response headerLink
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
.
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).