Open Bug 1390715 Opened 7 years ago Updated 2 years ago

Web page would not display (Error:WebExtension context not found!) after several navigation if extension "Zoom Page We" is installed

Categories

(WebExtensions :: Compatibility, defect, P3)

57 Branch
x86_64
Windows 10
defect

Tracking

(Not tracked)

People

(Reporter: alice0775, Unassigned)

References

Details

(Whiteboard: investigate)

Attachments

(1 file)

Attached file about:support
Build Identifier:
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20170815100349

Reproducible: always

Steps to Reproduce:
1. Install zoom-page-we 5.1 ( https://addons.mozilla.org/en-US/firefox/addon/zoom-page-we/ )
2. Restart browser

3. Open http://tunami.info/data/towndetail/352942/  in the current tab
   Open http://tunami.info/data/hazard_city/2386/  in the current tab
   Open http://tunami.info/data/citylist/27/  in the current tab
   ( Wait for tab throbber spinning to stop each time )

4. Click Back button 3 times ( Wait for tab throbber spinning to stop each time  )
5. Click Forward button 3 times ( Wait for tab throbber spinning to stop each time  )

6. Repeat step 4 and step 5 until page is blank (It may need to repeat step6 more than 5 times)

7. Optionally after step 8, Open https://www.google.co.jp/ in the current tab

Actual Results:
Web page would not display, is blank.

Browser Console show:
Error: WebExtension context not found!  ExtensionParent.jsm:814:13



Expected Results:
Web page should display
> 4. Click Back button 3 times ( Wait for tab throbber spinning to stop each time  )
> 5. Click Forward button 3 times ( Wait for tab throbber spinning to stop each time  )

It seems to be easier to reproduce if you click Back/Forward while tab throbber spinning.

4. Click Back button 3 times
5. Click Forward button 3 times
See Also: → 1389496
In this case, the problem is reproduced regardless of extensions.webextensions.remote setting.
I can confirm that this problem is caused by Zoom Page WE.

For some reason, for these particular pages, the content script is not seeing the DOMContentLoaded event or the readyState is incorrectly set.

I need to investigate further.
Component: WebExtensions: Untriaged → WebExtensions: Compatibility
Priority: -- → P3
Currently on Firefox the WE content scripts are not destroyed and re-injected while navigating the tab history,
e.g. in the react-devtools I've proposed a change to their content script which added a "pageshow" event listener to detect it while the user is navigating the history:

https://github.com/facebook/react-devtools/pull/830#issue-240972521

I'm adding a needinfo assigned to me to investigate it further.
Flags: needinfo?(lgreco)
Whiteboard: investigate
The fact that the content script is not re-injected while navigating the tab history seems to me to be a fundamental issue.

I have not seen this behaviour mentioned the WebExtensions documents (but I may have missed it).

How can the "run_at": "document_start" or "run_at": "document_end" manifest directives be obeyed if the content script is not re-injected, or at least re-executed from the beginning?
Product: Toolkit → WebExtensions
I think I may be experiencing the same problems (content scripts not being re-injected in some documents, and the "WebExtension context not found!" error), with an extension that I'm developing.

I'd like to provide useful information for this problem, but I'm not sure how to debug the "WebExtension context not found!" error. I have tried using about:debugging and the debugger in the content script's tab, but it doesn't seem possible to catch the exception and get a trace to know what exactly caused it. Any pointers would be appreciated. Perhaps then we can create a minimal example.

(I'll be away for most of the coming week, but will try to keep up, and help out when back if I can.)

Here is some extra information:

* My extension uses ports for communication between the content and background scripts, not message-passing (like the extension Luca patched). The ports stuff seems especially prone to cause the "WebExtension context not found!" error, even if it works after the error (which it does, in most cases). I am using a work-around for the fact that the background script is only loaded after content scripts for existing tabs when the extension is installed/started, which does work. Details on that are at bug 1474727 comment 3.

* Even when I am handling the 'pageshow' event in my content script, when I go far enough back in the history, I get the "WebExtension context not found!" error and the event handler doesn't run. It does run at other times (verified by logging whenever it's called).

* That last problem extends to none of the content script being (re-)run at some stage when going back in the history (it always happens at three steps back for me, so far, once I've looked at some other tabs first, before starting to go back).

* I get the "WebExtension context not found!" error for the first two steps back in the history too, but everything works as expected then (i.e. the content script runs).
Apologies; minor update: I just added some extra debugging in the background script and changed my test procedure to completely close Firefox between loads of the extension (strangely web-ext was not causing full reloads when the directory changed, so I was using about:debugging to reload), and I can see that the 'pageshow' handler *does* get handled when the older content script is encountered. This, you would think, would solve the problem, as the code tries to reconnect to the background script there.

However, what happens is that it is able to reconnect to the background script, actually manages to send one message, but then encounters the "WebExtension context not found!" error again and all communication stops.

So Luca's workaround does appear to work, but I am still getting "WebExtension context not found!" errors shortly after connecting to the background script from the older non-reinjected content script.

(I tested this loads before sending my first comment, but the idea of adding some more debugging to the background and fully closing Firefox only occurred afterwards, d'oh. The apparent intermittency of this is a concern, but hopefully I can provide some useful info once I've learnt how to trace the context error.)
Following more testing, I have some updates:

 * Disabling Firefox's back-forward cache ("bfcache") by attaching an event handler to window.onunload appears to solve this problem entirely, as the whole page and the content script are re-loaded when the page is re-visited by the user.

 * The "pageshow" event handler correctly runs when the content script is brought out of bfcache, but the communication with the background page soon fails, and I get that "WebExtension context not found!" error. If I go back far enough in the history, I get to a point where it breaks (consistently three pages back, though I have to have at least one other tab open to switch between before traversing back in the history on the affected tab).

 * If, after this breakdown, I move forward to a page that was working, it still works, though I still also get the "WebExtension context not found!" - at that point, moving back again to the page that suffers the communications breakage causes its "pageshow" to fire again, but I still get the same zero or one message through the port before it breaks again.

Seems like this is a problem with communication ports after a page is brought out of bfcache?

But, more importantly, I've still not been able to get a stack-trace or reason for the "WebExtension context not found!" errors that are popping up a lot. A colleague of mine suggested editing the Firefox code to find out more about why the error is occurring; that seems to be the next step.
I've done some more testing, by checking out the latest publicly-released version of my extension (<https://addons.mozilla.org/en-GB/firefox/addon/landmarks/versions/?page=1#version-2.3.1>), which predates the switch to port-based communication. I found that the same problem occurs as described in the above comment, so the comms breakdown problem really seems to be related to the bfcache, rather than using ports instead of message-passing for internal extension communication.
Flags: needinfo?(lgreco)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: