this.viewNode is null error when calling window.close()
Categories
(WebExtensions :: Untriaged, defect, P2)
Tracking
(firefox66 verified, firefox67 verified)
People
(Reporter: hello, Assigned: robwu)
Details
Attachments
(3 files)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:64.0) Gecko/20100101 Firefox/64.0
Steps to reproduce:
Porting an extension from Chrome to Firefox (works fine in Chrome, but love Firefox).
When a user clicks on the extension, if credentials are not found in chrome.storage.local, chrome.runtime.openOptionsPage() is called followed by window.close().
In a nutshell, the user then logs in via options and the cycle repeats but credentials are found this time so the popup is rendered.
This works fine the first time around, but when the extension is clicked again (no login attempted, same cycle), the following error is thrown.
this.viewNode is null ExtensionPopups.jsm:492
attach
resource:///modules/ExtensionPopups.jsm:492:5
InterpretGeneratorResume self-hosted:1255:8 next self-hosted:1210:9 onViewShowing
chrome://browser/content/parent/ext-browserAction.js:196:33
next self-hosted:1210:9 wrapWidgetEventHandler/aWidget[aEventName]
resource:///modules/CustomizableUI.jsm:2509:16
dispatchCustomEvent
resource:///modules/PanelMultiView.jsm:194:5
dispatchCustomEvent
resource:///modules/PanelMultiView.jsm:1254:12
dispatchAsyncEvent/this._blockersPromise<
resource:///modules/PanelMultiView.jsm:228:20
InterpretGeneratorResume self-hosted:1255:8 next self-hosted:1210:9
For reference, this bug has been discussed with erosman and @freaktechnik on IRC #webextensions.
Actual results:
The content of the popup is cleared, but the popup isn't closed.
Expected results:
The popup should close.
Assignee | ||
Comment 1•5 years ago
|
||
str |
Steps to reproduce:
- Load extension, e.g. at about:debugging
- Click on the popup
Expected:
- Popup should close.
Actual:
- Popup is not closed.
- The global JS console (Ctrl-Shift-J) contains the following error:
this.viewNode is null ExtensionPopups.jsm:492
Reproduced on Firefox 64.0 and Firefox 66.0a1 buildID 20190103094209
Assignee | ||
Comment 2•5 years ago
•
|
||
I've also observed the following error in a local build:
"TypeError: this.browser is null ExtensionPopups.jsm:338:7"
Edit: that is likely bug 1394019
Assignee | ||
Comment 3•5 years ago
|
||
Assignee | ||
Comment 4•5 years ago
|
||
There is already an existing unit test that tests the scenario of closing a popup on load:
https://searchfox.org/mozilla-central/rev/c3ebaf6de2d481c262c04bb9657eaf76bf47e2ac/browser/components/extensions/test/browser/browser_ext_browserAction_popup.js#55-61
The test does however not fail, possibly because it does not trigger the pre-load branch.
I've locally verified that my proposed patch fixes the reported bug, but QA should also confirm that the bug has been fixed when the patch lands.
Comment 5•5 years ago
|
||
IIUC the popup doesn't close in this situation. Does the test popup also not close? If so, can we add a check that the popup actually closes?
Assignee | ||
Comment 6•5 years ago
|
||
The test file that I referenced does not test preloaded popups.
I have just added a new test that does test preloaded popups, and I verified that the test fails before my fix and passes after with the patch. I have also made some other small changes to fix errors (including bug 1394019, which is triggered by my new test).
Reporter | ||
Comment 7•5 years ago
|
||
I see you guys are doing great progress. Thanks. :) Do you have ETAs for when the fix will be released to Nightly and then to everyone?
I will keep an eye open and try the fix as soon as its published.
Updated•5 years ago
|
Pushed by rob@robwu.nl: https://hg.mozilla.org/integration/autoland/rev/d27e22f625f2 Return early if popup has already been closed r=mixedpuppy
Comment 9•5 years ago
|
||
bugherder |
Comment 10•5 years ago
|
||
https://hg.mozilla.org/projects/cedar/rev/d27e22f625f26ba6ae485d5da99f4b5ded52e065 Bug 1518598 - Return early if popup has already been closed r=mixedpuppy
Comment 11•5 years ago
|
||
Verified the fix using FF 66.0a1 and the latest Nightly (20190203214209), I did manage to reproduce the issue using the attached extension from comment #1 while using Fx 64, 65 but the error was no longer showing on versions above 66. Testing was done on Windows 10 x64 bit.
Description
•