1447806 - Error: WebExtension context not found!

Status: NEW

(WebExtensions :: General, defect, P3)

Description

[Kris Maglione [:kmag]]

This bug was automatically filed from Sentry: https://sentry.prod.mozaws.net/operations/nightly-js-errors/issues/2045118/

Error: WebExtension context not found!

resource://gre/modules/ExtensionParent.jsm

Comment 1

[Matthew Tylee Atkinson]

I've been finding this error a lot in my logs, and it appears that it may be related to port-based communication between content and background scripts, and possibly a problem that is caused/exacerbated by the bfcache. In case it's of use, there's some info on bug 1390715 comment 8 (and the comments leading up to it). The work-around in that bug didn't work for me - I think this is because I'm using port-based rather than message-passing communication within my extension.

Comment 2

[Matthew Tylee Atkinson]

I have a small update: as per bug 1390715 comment 9, it seems the problems I'm finding, and possibly the "Error: WebExtension context not found!" message, may be being triggered by the bfcache rather than the extension using port-based communication instead of message passing for internal communication (I tested a version that didn't use ports and got the same problems).

Comment 3

[Graham Leggett]

I'm finding this error in my logs, and I have no idea whether this error is relevant to the problem I am trying to debug or whether this message is noise from something else.

Someone hunted down the code, and we have an excessive vague error message:

https://stackoverflow.com/questions/49051084/firefox-console-error-webextension-context-not-found

getContextById(childId) {
let context = this.proxyContexts.get(childId);
if (!context) {
let error = new Error("WebExtension context not found!");
Cu.reportError(error);
throw error;
}
return context;
}

The message "WebExtension context not found!" should be "WebExtension context '" + childId + "' not found!".

Comment 4

[Rob Wu [:robwu]]

This error can occur when an extension API is called shortly before the context disappears.

Bug 1905505 is an example where many errors like these were triggered: in that case the event page terminated too soon, and any pending extension API calls arrived over IPC after the context went away.

Here is a relevant comment about the implementation detail:

• ParentAPIManager.recvAPICall resets the timer before processing an API call. Before it gets there, it looks up the context via getContextById, which throws if the context has already been unloaded. Experimentally I confirmed that unloading the background event browser via setBgStateStopped triggers a synchronous message-manager-close notification that erases the context. If we ever decide to drop the use of this notification in favor of recvConduitClosed (which is tracked in bug 1595186), then we have to carefully examine that doing so will not cause bugs like this ("this" referring to bug 1905505).

Bug 1595186 is about moving away from message-manager-close to Conduits, which would slightly extend the lifetime of a "context" in the parent until when all API calls and messages from the content has been processed (recvConduitClosed). Doing so would reduce the frequency of this reported error because then the recvAPICal / recvAddListener / etc. handlers would use the same IPC mechanism as the "context unload" mechanism.

If changing the timing of "context unload" is undesirable, then we could still reduce the number of reported errors by temporarily storing the ID when at message-manager-close, until recvConduitClosed (and use the presence of the ID to suppress the error message or make it more useful).

Comment 5

[Rob Wu [:robwu]]

(S3 -> S4: work-around is to not look at the log)