1726978 - Content script is not injected correctly

Status: RESOLVED WORKSFORME

(WebExtensions :: General, defect)

Description

[robbendebiene]

Attachment: example.zip

A user of my add-on reported that it doesn't work on the following website: https://archive.newsletter2go.com/?n2g=t3umlphz-doffwyqv-jrg

After some investigations my conclusions is that the content script is not injected or re-injected correctly. In order to test the problem I've attached a simple example extension.

1. Open a tab with https://archive.newsletter2go.com/?n2g=t3umlphz-doffwyqv-jrg
2. Load the example extension
3. Click somewhere in the page
4. Notice the alert

If the given page is already loaded and one loads/reloads the add-on the content script is correctly applied. (you will see an alert when you click the page). However once you reload the page clicking it will not show the alert anymore. So basically if you swap step 1 and 2 it won't work anymore.

It seems like the document is loaded twice (or replaced by another document), but the content script is only injected in the first document which is immediately discarded.

Comment 1

[Yves Goergen [:ygoe]]

I've also noticed that the DOM inspector shows strange data about that page. When I open it after the page has been loaded, it's completely empty! No document at all. Reloading the page shows an entirely empty document. (The document tree seems to change twice during loading that page.) Pointing at an element to pick then finally shows the document tree. This is a very strange document.

Comment 2

[Rob Wu [:robwu]]

The content script is injected, but the listener added by it is removed later, because the web page uses document.write() to replace the document after the load. That removes all existing listeners on window and the document.

Minimal STR (independent of extensions!):

1. Visit http://example.com
2. Open console and run window.addEventListener("click", console.log);
3. Click in the document. --> Result: logged message.
4. Run document.write("xx");
5. Click in the document.
6. Result: no logged message, indicating that the listener has been removed.

This behavior also happens in Chrome; it's standardized behavior, see the external spec and tests referenced at bug 1489308.
This is also documented at https://developer.mozilla.org/en-US/docs/Web/API/Document/write and https://developer.mozilla.org/en-US/docs/Web/API/Document/open, as "All event listeners currently registered on the document, nodes inside the document, or the document's window are removed.".

(In reply to Yves Goergen from comment #1)

I've also noticed that the DOM inspector shows strange data about that page. When I open it after the page has been loaded, it's completely empty! No document at all.

Sounds like bug 1626565.

I'm closing the issue because the observed behavior is not incorrect, but I'm not opposed to a new feature request to allow extensions to more effectively deal with this situation.

Comment 3

[robbendebiene]

Thanks for the detailed clarification!

Do you know any other way to detect this "document change" apart from monkey patching the write/open functions or using an MutationObserver?

but I'm not opposed to a new feature request to allow extensions to more effectively deal with this situation.

Do you have any ideas in mind on how this functionality could be exposed to extension developers? Another property similar to match_about_blank?

Comment 4

[Rob Wu [:robwu]]

(In reply to robbendebiene from comment #3)

Thanks for the detailed clarification!

Do you know any other way to detect this "document change" apart from monkey patching the write/open functions or using an MutationObserver?

I'm out of good ideas. I've considered monkey-patching, MutationObservers and timers, but these are all gross hacks.

but I'm not opposed to a new feature request to allow extensions to more effectively deal with this situation.

Do you have any ideas in mind on how this functionality could be exposed to extension developers? Another property similar to match_about_blank?

I'm not sure if a manifest key is the best way to do it. After all, the content script is already injected, and the script is still running (including any previously scheduled timers). Therefore, it may be more useful to introduce a new event, e.g. in the dom namespace. This namespace doesn't exist in Firefox, but Chrome already has it: https://source.chromium.org/chromium/chromium/src/+/main:chrome/common/extensions/api/dom.json?q=file:extensions%20dom&ss=chromium

If the web platform is up for it, it may be even more useful to have such an event on the window or document, since this is really not extension-specific. If you're taking this road, the WHATWG may be a good group. If your idea is extension-specific, then you could also consider the WebExtensions Community group at https://github.com/w3c/webextensions.