window.close() inside webextensions popup focuses parent window
Categories
(WebExtensions :: Frontend, defect)
Tracking
(Not tracked)
People
(Reporter: markus.stefanko, Unassigned, NeedInfo)
Details
(Keywords: regressionwindow-wanted)
Attachments
(1 file)
5.39 KB,
application/zip
|
Details |
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:75.0) Gecko/20100101 Firefox/75.0
Steps to reproduce:
- In a webextension popup we try to focus another window with browser.windows.update(windowId, {focused: true})
- After the click we manually close the popup with window.close()
I am not sure this is a bug, it seems to be unexpected behavior though that the extension popup's parent would gain focus when calling window.close() on the popup.
This behavior does not exist in Chrome.
Actual results:
- The other window gets correctly focus
- The original window ( where the popup was opened ) regains focus
Expected results:
- The other window gets correctly focus
This seems to be only happening on Windows. Users reported this behaviour on Windows 10 and FF 75. I was able to reproduce in a Win 7 VM with FF 75 as well.
I wasn't able to reproduce this behaviour on MacOS.
Updated•5 years ago
|
Comment 2•5 years ago
|
||
Hello ms,
From my understanding the 'browser.windows.update(windowId, {focused: true})' line would be part of the background script but not window.close() as it would have to be run as a separate command. Is that correct?
Could you please provide the extension you've used to test this and perhaps a recording of the issue?
Thank you
Comment 3•5 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
Comment 4•5 years ago
|
||
Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is --
(non,) indicating it has has not been previously triaged, the bug's Severity is being updated to --
(default, untriaged.)
Comment 5•5 years ago
|
||
Hello ms,
As per the request from Comment 2, could you please provide the extension you used to test the issue and possibly a screen recording?
Thank you !
Comment 6•5 years ago
|
||
Please see comment above.
Comment 8•5 years ago
|
||
The attached zip file contains a small test extension that should be doing what comment 0 is describing.
STR:
- Make sure to open 2 non overlapping Firefox windows (e.g. two windows side by side)
- Click on the browser action in one of the two windows
- Click on the close button in the browser action popup
- Expected behavior: the browser action popup should be closed and the other window should be focused
(use a keyboard shortcut, e.g. Ctrl-T to open a new tab in the currently focused window, if it isn't clear which window is currently focused)
I've also tried this test extension (on Linux on a Nightly 79 build) but I wasn't able to trigger the unexpected behavior (the windows focused was the one focused by the browser.windows.update API call).
Comment 9•5 years ago
|
||
would you mind to check: if the test extension attached is
- triggering the same issue that you are describing in comment 0 for you (as I did mention in comment 8 I wasn't able to reproduce it with this test extension)
- doing anything different from what your extension is actually doing (and that would prevent the attached test extension to be able to trigger the issue)
Comment 10•5 years ago
|
||
Hi Miruna,
I've just attached a test extension that be doing what comment 0 is describing, could you give it a try to find if a regression range can be found?
(as I did mention in comment 8 I wasn't actually able to reproduce the issue as described, but I only tried on Nightly and on Linux, and so there is a chance that it may trigger the issue in previous Firefox versions or other platforms).
Comment 11•5 years ago
|
||
Hello,
I was unable to reproduce the issue using the test extension and STR from Comment 8 on the latest Nightly (79.0a1/20200611093454), Beta (78.0b6/20200611192304) and Release (77.0.1/20200602222727) on Windows 10 Pro 64-bit and Ubuntu 16.04 LTS.
I’ve also attempted to reproduce the bug on older Release versions (75.0/20200403170909 and 73.0.1/20200217142647) on both OSes mentioned above, however with no success in replicating the issue.
In each tested case, as soon as the pop-up is closed, focus is switched to the other window.
Comment 12•5 years ago
|
||
I'm closing this as incomplete.
Mark, feel free to reopen this issue if it turns out that you are able to reproduce it consistently with the test extension attached (or if you can extend that minimal test extension to make it able to trigger the issue consistently).
Description
•