Closed bershanskiy closed 6 months ago
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).
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
extensionTypes.RunAt
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:webRequest.StreamFilter
to rewrite the document and insert a<script>
tag which would execute synchronously.proxy
API to redirect request to a native HTTP proxy which would rewrite the response and add the<script>
tagwebRequest
API to listen foronHeadersReceived
and add HTTP response headerLink
to preload the script - very unreliableProposal
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 calledscripting.before_document_start
orscripting.synchroneous
.