Closed Bug 1535674 Opened 7 years ago Closed 7 years ago

Pinned tabs don't restore with the `await` fix

Categories

(Core :: JavaScript Engine, defect, P1)

Product:
Core
Component:
JavaScript Engine
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla68
Tracking Flags:
Tracking Status
firefox68 --- verified

People

(Reporter: jorendorff, Assigned: aswan)

References

(Blocks 1 open bug)

Details

Attachments

(2 files, 1 obsolete file)

compare.js
430.76 KB, application/x-javascript
Details
Bug 1535674 Fix race with webextension persistent listeners r=kmag
47 bytes, text/x-phabricator-request
Details | Review

See bug 1534806. The await fix causes problems in session restore, presumably due to a race condition somewhere. Hard to tell exactly where; multiple processes are involved.

The await fix is backed out for now, but this has to be fixed before it can reland.

Session restore is implemented by SessionStore.jsm, in the parent process, and ContentSessionStore.jsm in content processes.

According to mconley, summarized:

The parent is under the impression that the content is about to navigate somewhere, but content either doesn't receive that message, doesn't do anything with that message, or doesn't cause any visual changes or progress updates to occur as a result of that message.

To start, see if these messages are being received by the content process for the tabs that are in the bad state.

Assuming they're received, check to see what's happening inside restoreHistory and restoreTabContent in that file. When restoring a pinned tab, restoreHistory should be received first per tab, and then restoreTabContent, for the ones that are being restored immediately.

If both are being received, based on the video, mconley would start with ensuring that restoreHistory is correctly setting the back/forward history for the tab, here.

Then, step through https://searchfox.org/mozilla-central/source/browser/components/sessionstore/ContentRestore.jsm#167

What we're really hoping is that a loadURI occurs, like here or here, to actually load the page:

If we're not reaching either of those, that's the problem.

If we are reaching those, and we're still not loading the page, then there's a problem in the underlying DocShell stuff.

Priority: -- → P1
Attached file compare.js —
Assignee: nobody → jorendorff

I added a line to dump JSON.stringify(winData) here, and I got different values when the await fix was enabled.

The attached file contains the actual data. Here are the Object.keys(winData) only:

good  (no await fix): tabs,selected,width,height,screenX,screenY,sizemode,__lastSessionWindowID
bad (with await fix): tabs,selected,_closedTabs,busy,sizemodeBeforeMinimized,width,height,screenX,screenY,sizemode,zIndex

So to summarize the story so far: the patch in bug 1495072 reveals a race condition in Firefox startup code, apparently related to session restore and/or extensions; the winData suggests the race condition is in the parent process, and it happens quite early in startup.

Mike, any idea what might cause this? Or can you help me track this down?

Flags: needinfo?(mdeboer)

Hi Jason, sorry for the late reply - I'll have time to look into this tomorrow.

Flags: needinfo?(mdeboer)

Mike, did you have a chance to look at this?

Flags: needinfo?(mdeboer)

(In reply to Jason Orendorff [:jorendorff] from comment #3)

I added a line to dump JSON.stringify(winData) here, and I got different values when the await fix was enabled.

The attached file contains the actual data. Here are the Object.keys(winData) only:

good  (no await fix): tabs,selected,width,height,screenX,screenY,sizemode,__lastSessionWindowID
bad (with await fix): tabs,selected,_closedTabs,busy,sizemodeBeforeMinimized,width,height,screenX,screenY,sizemode,zIndex

I'm interested in learning the difference in stack-traces as well, because they must've been called from different places.

Also, this is likely to uncover a rather large issue that may be causing quite a number of other issues that I've been unable to classify before.

So to summarize the story so far: the patch in bug 1495072 reveals a race condition in Firefox startup code, apparently related to session restore and/or extensions; the winData suggests the race condition is in the parent process, and it happens quite early in startup.

Mike, any idea what might cause this? Or can you help me track this down?

The only thing - now that I finally have a bit more control over my own schedule - I can do is to debug this together and go step-by-step until we find the real culprit.
I'm in the unfortunate state that I can only debug artifact builds, but shouldn't be a real problem here, right?

Flags: needinfo?(mdeboer)

Mike and I took a look at this today.

We think the problem is in the content process. ContentRestoreInternal.restoreTabContent is called for the tabs that don't restore properly, but they aren't being restored.

(Incidentally, there is a huge try-block in that method that simply squelches all exceptions. But a dump() there did not hit, so apparently that's not the issue this time.)

<mikedeboer> jorendorff: I think I figured out the cause... and it's not something related to your changes,
    more something that got unveiled by them
<mikedeboer> jorendorff: still gotta try something to see if that's 100% the cause, but it's quite likely.

(suspense intensifies)

Unfortunately, what I thought might've been the cause was a red herring instead.

I narrowed it down to the following:

Interesting tidbit: This never happens the first time I start Firefox again after a ./mach build browser!
So I do ./mach build browser (regardless whether I made a change!), do ./mach run -P someProfile and all tabs finish restoring properly, because the progress-listener just works fine. I quit Firefox and each subsequent restart using ./mach run -P someProfile results in all tabs to restore to not finish loading, because the progress-listener doesn't work.

Depends on: 1510619

Extreme steps to reproduce:

  1. ./mach build browser

  2. ./mach run -P

    1. Clean up. If there is an existing test profile, select it, Delete Profile, Delete Files.
    2. Start. Create Profile. Next. Type test. Finish. The test profile is selected. Start Nightly.
    3. Install Facebook Container. Type addons.mozilla.org, Enter. Dismiss annoying door hanger. Click "Stay Safe Online". Scroll down to Facebook Container. Click "Add to Firefox". Add. Okay, Got It.
    4. Enable the await fix. Type Ctrl+L, about:config, Enter. Accept the Risk. Type await_fix. Toggle. Close the tab.
    5. Enable session restore. Click the Hamburger icon. Preferences. Check "Restore previous session". Close the tab.
    6. Pin some tabs. Click the new tab icon. Click "youtube". Right-click on the tab and Pin Tab. Repeat for reddit, wikipedia, and twitter. (Note: Not facebook, to dodge the whole issue of whether the addon's interaction with facebook is causing problems. Which it would—but later for that.)
    7. Quit cleanly. Click the Firefox Privacy Notice tab. Wait for the pinned tabs to finish loading. Type Ctrl+Q.

  3. ./mach run -P. The test profile is already selected. Start Nightly.

Expected: Pinned tabs load.

Observed: They don't.

Confirmed: It doesn't happen if I do all the same steps except for enabling the await fix. (I mean, obviously. But still.)

When we restart Nightly in step 3, in a good run (no await fix), ContentRestoreInternal.prototype.restoreTabContent is called five times, as expected.

In a bad run, it's called only three times (presumably because of MAX_CONCURRENT_TAB_RESTORES and the fact that the tabs never actually load).

I dumped this.tabData_ there and compared the tabData for reddit in good and bad runs. It's the same either way. The things that differ are stuff like .entries[1].ID, .entries[1].docshellUUID, and .lastAccessed.

(In reply to Jason Orendorff [:jorendorff] from comment #12)

In a bad run, it's called only three times (presumably because of MAX_CONCURRENT_TAB_RESTORES and the fact that the tabs never actually load).

Indeed. The max is three and we never get to send the signal back that it's ok to load more.

I dumped this.tabData_ there and compared the tabData for reddit in good and bad runs. It's the same either way. The things that differ are stuff like .entries[1].ID, .entries[1].docshellUUID, and .lastAccessed.

Indeed. So it's looking very much like your await fix is allowing us to consistently reproduce a serious bug in the DOM realm. I hope I flagged the appropriate people over at over at bug 1510619, because I suspect that once that one's resolved, this one will effectively be a no-op.

OK. I hope someone does look at it, but I'm going to keep plugging away too. I want this to ship.

Steps to reproduce in lldb on Mac OS X:

  1. ./mach build

  2. ./mach run -P

    1. Clean up. If there is an existing test profile, select it, Delete Profile, Delete Files.
    2. Start. Create Profile. Next. Type test. Finish. The test profile is selected. Start Nightly.
    3. Install Facebook Container. Type addons.mozilla.org, Enter. Dismiss annoying door hanger. Click "Stay Safe Online". Scroll down to Facebook Container. Click "Add to Firefox". Add. Okay, Got It. Cmd+W
    4. Enable the await fix. Type Cmd+T, about:config, Enter. Accept the Risk. Type await_fix. Toggle. Cmd+W.
    5. Enable session restore. Type Cmd+,. Check "Restore previous session". Cmd+W.
    6. Pin some tabs. Cmd+T. Click "youtube". Right-click on the tab and Pin Tab. Repeat for reddit, wikipedia, and twitter. (Note: Not facebook, to dodge the whole issue of whether the addon's interaction with facebook is causing problems.)
    7. Quit cleanly. Click the Firefox Privacy Notice tab. Wait for the pinned tabs to finish loading. Type Cmd+Q.

  3. ./mach run --disable-e10s --debug -- -P test.
    Type b nsSHistory::ReloadCurrentEntry, then r.

In this test case, loadArguments is always undefined, tabData.userTypedValue is always an empty string, and tabData.entries.length is always positive.

I stepped through one of the document loads. It seems to be an extremely typical, boring load from history. For the record,

restoreTabContent calls
-> nsSHistory::ReloadCurrentEntry, which tail-calls
-> nsSHistory::LoadEntry, which tail-calls
-> nsSHistory::InitiateLoad, which tail-calls
-> nsDocShell::LoadURI, which tail-calls
-> nsDocShell::LoadHistoryEntry, which calls
-> nsDocShell::InternalLoad, which calls
-> nsDocShell::DoURILoad, which calls
-> nsDocShell::DoChannelLoad, which tail-calls
-> nsDocShell::OpenInitializedChannel, which calls
-> nsURILoader::OpenURI which calls
-> nsURILoader::OpenChannel, which calls loader->Prepare() successfully and returns NS_OK.

One wrinkle: the channel is apparently redirected from another process (despite --disable-e10s??), so we call AsyncOpen here. That returns NS_OK (though I'm not clear on what it's doing).

Note that the stack in comment 14 is not necessarily the bad case. I took so long to step through it that some stuff timed out; I got sqlite errors and some of the pinned tabs loaded. One didn't. Inconclusive.

But here's the interesting bit.

Knowing the rest of the load would happen asynchronously, I set another breakpoint, in nsDocumentOpenInfo::DispatchContent, to see if I could catch the next step... but instead my existing breakpoint in nsDocShell::InternalLoad hit again, with an async function on the stack. This async function.

I'm not sure it's related, but it is an async function being resumed, in code that has something to do with extensions, loading a document, apparently racing with the loads that aren't working properly.

That's where I'll start tomorrow.

It is possible to add a short delay in an async function, like this:

await new Promise(resolve => setTimeout(resolve, 0));

The attached patch adds delays in several places in toolkit/components/extensions/ExtensionParent.jsm. The problem does not occur with these delays in place.

However, every test is about an 8-minute manual process, so I've only done about 3 test runs with delays and 3 without. (I'd be thrilled if using a backup tarball of a profile would give the same results, but I've seen the problem not occur with a saved profile even though the delays are commented out. Blah.)

The patch also adds a bunch of dump calls. The output looks like this:

Good run (with delays):

DEBUG-jorendorff - restoringDocument: <https://www.mozilla.org/en-US/privacy/firefox/>
DEBUG-jorendorff - calling history.reloadCurrentEntry()
DEBUG-jorendorff - restoringDocument: <https://www.youtube.com/>
DEBUG-jorendorff - calling history.reloadCurrentEntry()
DEBUG-jorendorff - new BackgroundPage - url is "moz-extension://5a4c670b-6df9-3e41-9f8d-9d94981b3ca1/_generated_background_page.html"
DEBUG-jorendorff - BackgroundPage.build()
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - in
DEBUG-jorendorff - new BackgroundPage - url is "moz-extension://0a42df92-76f5-ef40-b9cd-78017baf4f8b/_generated_background_page.html"
DEBUG-jorendorff - BackgroundPage.build()
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - in
DEBUG-jorendorff - new BackgroundPage - url is "moz-extension://de63d54a-682d-df4f-a8e8-5b4bd8e1b307/_generated_background_page.html"
DEBUG-jorendorff - BackgroundPage.build()
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - in
DEBUG-jorendorff - new BackgroundPage - url is "moz-extension://3ce1b0a8-a8e5-cd42-ad0b-190790186717/_generated_background_page.html"
DEBUG-jorendorff - BackgroundPage.build()
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - in
DEBUG-jorendorff - new BackgroundPage - url is "moz-extension://529700bf-5a92-064d-a8be-cecb5239bf10/_generated_background_page.html"
DEBUG-jorendorff - BackgroundPage.build()
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - in
DEBUG-jorendorff - new BackgroundPage - url is "moz-extension://4b007419-4da6-7444-9e29-21d0a2309aaa/_generated_background_page.html"
DEBUG-jorendorff - BackgroundPage.build()
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - in
DEBUG-jorendorff - restoringDocument: <https://www.reddit.com/>
DEBUG-jorendorff - calling history.reloadCurrentEntry()
DEBUG-jorendorff - restoringDocument: <https://www.wikipedia.org/>
DEBUG-jorendorff - calling history.reloadCurrentEntry()
DEBUG-jorendorff - restoringDocument: <https://twitter.com/>
DEBUG-jorendorff - calling history.reloadCurrentEntry()

Bad run (no delays, tabs don't load):

DEBUG-jorendorff - restoringDocument: <https://www.mozilla.org/en-US/privacy/firefox/>
DEBUG-jorendorff - calling history.reloadCurrentEntry()
DEBUG-jorendorff - restoringDocument: <https://www.youtube.com/>
DEBUG-jorendorff - calling history.reloadCurrentEntry()
DEBUG-jorendorff - new BackgroundPage - url is "moz-extension://17d6070c-b899-9345-8332-7f3a2a8182d9/_generated_background_page.html"
DEBUG-jorendorff - BackgroundPage.build()
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - in
DEBUG-jorendorff - new BackgroundPage - url is "moz-extension://54cc6b21-e631-e647-a0f0-59b846d86587/_generated_background_page.html"
DEBUG-jorendorff - BackgroundPage.build()
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - in
DEBUG-jorendorff - new BackgroundPage - url is "moz-extension://26a65cde-e220-d446-8ad8-fc16a3aca7ca/_generated_background_page.html"
DEBUG-jorendorff - BackgroundPage.build()
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - in
DEBUG-jorendorff - new BackgroundPage - url is "moz-extension://3d1f5251-6900-9c46-a1a6-894ff41760af/_generated_background_page.html"
DEBUG-jorendorff - BackgroundPage.build()
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - in
DEBUG-jorendorff - new BackgroundPage - url is "moz-extension://c147de35-fbb6-8f4f-a91c-2bcde49cc557/_generated_background_page.html"
DEBUG-jorendorff - BackgroundPage.build()
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - in
DEBUG-jorendorff - new BackgroundPage - url is "moz-extension://f78a7793-a253-ab45-949f-cf0050d1702f/_generated_background_page.html"
DEBUG-jorendorff - BackgroundPage.build()
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - in
DEBUG-jorendorff - restoringDocument: <https://www.reddit.com/>
DEBUG-jorendorff - calling history.reloadCurrentEntry()
DEBUG-jorendorff - HiddenXULWindow.initWindowlessBrowser - promiseObserved() resolved
DEBUG-jorendorff - HiddenXULWindow.initWindowlessBrowser - promiseDocumentLoaded(windowlessBrowser.document) resolved
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - waitInitialized resolved
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - awaiting awaitFrameLoader
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - waitInitialized resolved
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - awaiting awaitFrameLoader
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - waitInitialized resolved
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - awaiting awaitFrameLoader
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - waitInitialized resolved
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - awaiting awaitFrameLoader
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - waitInitialized resolved
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - awaiting awaitFrameLoader
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - waitInitialized resolved
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - awaiting awaitFrameLoader
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - awaitFrameLoader resolved
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - awaitFrameLoader resolved
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - awaitFrameLoader resolved
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - awaitFrameLoader resolved
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - awaitFrameLoader resolved
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - awaitFrameLoader resolved
DEBUG-jorendorff - BackgroundPage.build - browser created
DEBUG-jorendorff - BackgroundPage.build - browser created
DEBUG-jorendorff - BackgroundPage.build - browser created
DEBUG-jorendorff - BackgroundPage.build - browser created
DEBUG-jorendorff - BackgroundPage.build - browser created
DEBUG-jorendorff - BackgroundPage.build - browser created

And here is a miraculous good run with the delays commented out:

DEBUG-jorendorff - restoringDocument: <https://www.mozilla.org/en-US/privacy/firefox/>
DEBUG-jorendorff - calling history.reloadCurrentEntry()
DEBUG-jorendorff - hello from C++ - nsSHistory::ReloadCurrentEntry()
DEBUG-jorendorff - restoringDocument: <https://www.youtube.com/>
DEBUG-jorendorff - calling history.reloadCurrentEntry()
DEBUG-jorendorff - hello from C++ - nsSHistory::ReloadCurrentEntry()
DEBUG-jorendorff - restoringDocument: <https://www.reddit.com/>
DEBUG-jorendorff - calling history.reloadCurrentEntry()
DEBUG-jorendorff - hello from C++ - nsSHistory::ReloadCurrentEntry()
DEBUG-jorendorff - new BackgroundPage - url is "moz-extension://7880f1e7-d441-9044-843c-885c6438708a/_generated_background_page.html"
DEBUG-jorendorff - BackgroundPage.build()
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - in
DEBUG-jorendorff - HiddenXULWindow.initWindowlessBrowser - promiseObserved() resolved
DEBUG-jorendorff - HiddenXULWindow.initWindowlessBrowser - promiseDocumentLoaded(windowlessBrowser.document) resolved
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - waitInitialized resolved
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - awaiting awaitFrameLoader
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - awaitFrameLoader resolved
DEBUG-jorendorff - BackgroundPage.build - browser created
DEBUG-jorendorff - restoringDocument: <https://www.wikipedia.org/>
DEBUG-jorendorff - calling history.reloadCurrentEntry()
DEBUG-jorendorff - hello from C++ - nsSHistory::ReloadCurrentEntry()
DEBUG-jorendorff - new BackgroundPage - url is "moz-extension://b7690f1f-da0f-9843-9d5a-abb0c2b14a73/_generated_background_page.html"
DEBUG-jorendorff - BackgroundPage.build()
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - in
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - waitInitialized resolved
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - awaiting awaitFrameLoader
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - awaitFrameLoader resolved
DEBUG-jorendorff - BackgroundPage.build - browser created
DEBUG-jorendorff - new BackgroundPage - url is "moz-extension://31a824dc-b34d-e246-9aa6-0476fea63ee3/_generated_background_page.html"
DEBUG-jorendorff - BackgroundPage.build()
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - in
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - waitInitialized resolved
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - awaiting awaitFrameLoader
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - awaitFrameLoader resolved
DEBUG-jorendorff - BackgroundPage.build - browser created
DEBUG-jorendorff - new BackgroundPage - url is "moz-extension://79b9a0cf-79a8-5149-9975-6275a1216c78/_generated_background_page.html"
DEBUG-jorendorff - BackgroundPage.build()
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - in
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - waitInitialized resolved
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - awaiting awaitFrameLoader
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - awaitFrameLoader resolved
DEBUG-jorendorff - BackgroundPage.build - browser created
DEBUG-jorendorff - new BackgroundPage - url is "moz-extension://1cffde86-65ad-0c43-898a-ee747955911a/_generated_background_page.html"
DEBUG-jorendorff - BackgroundPage.build()
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - in
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - waitInitialized resolved
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - awaiting awaitFrameLoader
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - awaitFrameLoader resolved
DEBUG-jorendorff - BackgroundPage.build - browser created
DEBUG-jorendorff - new BackgroundPage - url is "moz-extension://a3ac0208-e798-184b-aa68-c364fd0a07ae/_generated_background_page.html"
DEBUG-jorendorff - BackgroundPage.build()
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - in
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - waitInitialized resolved
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - awaiting awaitFrameLoader
DEBUG-jorendorff - HiddenXULWindow.createBrowserElement - awaitFrameLoader resolved
DEBUG-jorendorff - BackgroundPage.build - browser created
DEBUG-jorendorff - restoringDocument: <https://twitter.com/>
DEBUG-jorendorff - calling history.reloadCurrentEntry()
DEBUG-jorendorff - hello from C++ - nsSHistory::ReloadCurrentEntry()

I think this is a bug in either EventManager or webRequest. Starting here:
https://searchfox.org/mozilla-central/rev/d33d470140ce3f9426af523eaa8ecfa83476c806/toolkit/components/extensions/parent/ext-webRequest.js#28-35

For a primed webRequest listener, fire here is this stub:
https://searchfox.org/mozilla-central/rev/d33d470140ce3f9426af523eaa8ecfa83476c806/toolkit/components/extensions/ExtensionCommon.jsm#2127-2136

But once wakeup() has resolved (in ext-webRequest.js line 30) that stub is no longer usable.

Not sure yet what the right fix is, wanted to get this written down before I get distracted by something else and forget the details!

I guess a quick fix would be for EventManager.clearPrimedListeners to set a flag somewhere to indicate that the background page has been restored and this primed listener was not re-added. Then the stub fire implementation can immediately reject if that flag is set.

I also neglected to mention, this is failing since facebook container doesn't create its webRequest listener(s?) synchronously from its background script, I'll file a separate bug for that.

Ah, facebook container already has:
https://github.com/mozilla/contain-facebook/issues/206

This is not yet thoroughly tested. Automated testing would be ideal
of course but I'm not sure exactly how to do it...

Okay, this should be testable. It looks like we don't have any tests for the wakeup() functionality added to primed event listeners. It should be relatively straightforward to add to test_ext_persistent_events.js

Assignee: jorendorff → aswan
Attachment #9059041 - Attachment description: Bug 1535674 proposed fix → Bug 1535674 Fix race with webextension persistent listeners r=kmag

https://hg.mozilla.org/mozilla-central/rev/1305877ca306

Status: NEW → RESOLVED
Closed: 7 years ago
status-firefox68: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
Blocks: 1510619, 1546145
No longer blocks: 1495072
No longer depends on: 1510619

Got around to running through the manual steps again, just to make sure. It works!

Status: RESOLVED → VERIFIED
Attachment #9058994 - Attachment is obsolete: true

Thanks so much, Jason for the heroic efforts to get to the bottom of this and Andrew, Kris for the super-rapid response and fix, once the culprit became known!!

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: