1694927 - Firefox 86.0 brings existing window into focus, when windowReference.location.href is called

Status: VERIFIED FIXED

(Core :: DOM: UI Events & Focus Handling, defect, P1)

Description

[vorstand]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:86.0) Gecko/20100101 Firefox/86.0

Steps to reproduce:

1.) try to get an existing window with name "anyname":
var windowRef = http://window.open("", "anyname");

2.) then write a new URL into it:
windowRef.location.href = "http://domain.com/file.html";

Actual results:

The window with name "anyname" and reference "windowRef" gets "automatic" focused, just like an additional:
windowRef.focus();

Expected results:

The existing window with name "anyname" and reference "windowRef" should stay in the background and should not "steal" the focus.

This was the usual behavior since I remember and is still the default behavior of other Browsers, I have tested with.

Comment 1

[vorstand]

Sorry, typo, of course, the first step should be:
var windowRef = window.open("", "anyname");

Don't know how the "http" got in.

Comment 2

[Florencia Di Ciocco, NI to vbalducci]

Hi Vorstand,

Could you please attach an example? Like an HTML file or upload the example to some platform and then share the link?

I tried doing it myself, but I didn't get very far.

Thanks, Flor.

Comment 3

[vorstand]

Attachment: main.html

Main file to demonstrate the bug. Open this first, please

Comment 4

[vorstand]

Attachment: popup.html

Second file, has to be invoked from first file "main.html"

Comment 5

[vorstand]

(In reply to Florencia Di Ciocco, QA from comment #2)

Hi Vorstand,

Could you please attach an example? Like an HTML file or upload the example to some platform and then share the link?

I tried doing it myself, but I didn't get very far.

Thanks, Flor.

Hi Flor,

I attached two HTML-file to demonstrate this "new" strange behavior of Firefox 86. You have to download both files on your local drive and open "main.html". I hope the code is "self-explanatory".

best regards,
v.

Comment 6

[Florencia Di Ciocco, NI to vbalducci]

V,

Thanks so much for the details. I was able to reproduce the bug on Windows 10 on FF Nightly 88.0a1 , Beta 87.0b3, FF release 86.0,.

As the reporter says, this is a regression because it doesn't occur on 78.8esr.

I've chosen a component. If you consider that there's another component that's more proper for this case you may change it.

Best regards, Flor.

Comment 7

[Tom S]

Thanks for the great test case!

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=57c02aedb3c8f5c2126e5b739f11cbf0e30d134e&tochange=d3539dfe1b07c4937e084844999c515475e869bb

Comment 8

[Emilio Cobos Álvarez (:emilio)]

So it's a bit weird that other browsers behave differently here for location.href = "location" and window.open("name", "location"), but seems they do... Curious when do you want it not to take the focus?

Comment 9

[vorstand]

The problem with this "new" focus behavior is that, till Firefox 85, the focus was never taken away and the "old" behavior had existed for years. And all other browsers also behaved like this since the beginning of time, I think. I unterstand, that the "new" focus behavior could be viewed as a new feature and not as a bug, but actually I really have a case in which this causes difficulties: I programmed about five years ago something for a customer in which there is a main window and a data entry pop-up that can be moved on the screen. The popup "disappears" now into the background when it refreshes the main window. Of course I programmed a workaround, but it's not a nice one, because now the pop-up always disappears for a millisecond or so into the background and then has to be brought back to the foreground by the main window. The customer has therefore already switched to Microsoft Edge because it's a little bit annoying to enter her data with Firefox on smaller screens and with a maximized main window. If Firefox insist of "stealing" the focus after submitting a "location.href" I have to use more complicated ways to refresh the main window, using more Javascript or more "sophisticated" communication between the windows. But all this I have to figure out first.

Thank you for your help and support,
best regards
V.

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

Added those dependencies since they might be all about the same issue.

Comment 11

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1694927 - Don't allow location APIs to steal focus. r=smaug

The check was a bit too general it seems. Explicitly allow moving focus
for link clicks and window.open(), which are the things we have tests
for and care about moving focus.

Comment 12

[Emilio Cobos Álvarez (:emilio)]

[Tracking Requested - why for this release]: Regression with multiple dupes

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f7e65191475a
Don't allow location APIs to steal focus. r=smaug,hsivonen

Comment 14

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/f7e65191475a

Comment 15

[Emilio Cobos Álvarez (:emilio)]

Comment on attachment 9206586 [details]
Bug 1694927 - Don't allow location APIs to steal focus. r=smaug

Beta/Release Uplift Approval Request

• User impact if declined: Unexpected behavior with some popup which bring the window to the front when using the location APIs.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: comment 0 and test-case attached to the bug.
• List of other uplifts needed: none
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Explicitly allow some code paths for the code bringing focus to the navigated window. Should be fairly low-risk.
• String changes made/needed: none

Comment 18

[Julien Cristau [:jcristau]]

Comment on attachment 9206586 [details]
Bug 1694927 - Don't allow location APIs to steal focus. r=smaug

approved for 87.0b6

Comment 19

[Julien Cristau [:jcristau]]

https://hg.mozilla.org/releases/mozilla-beta/rev/15d301be7382

Comment 21

[Florencia Di Ciocco, NI to vbalducci]

Hi,

I've verified that this bug is no longer present on Beta 87.0b7 nor on nightly 88.0a1 (2021-03-08) .

Regards, Flor.

Comment 23

[Pascal Chevrel:pascalc]

Emilio, I'd like to take this patch in an 86 dot release, could you request uplift to release? Thanks

Comment 24

[Emilio Cobos Álvarez (:emilio)]

Comment on attachment 9206586 [details]
Bug 1694927 - Don't allow location APIs to steal focus. r=smaug

Beta/Release Uplift Approval Request

• User impact if declined: comment 0 and dupes
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: comment 0 et al.
• List of other uplifts needed: none
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): see comment 15
• String changes made/needed: none

Comment 25

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9206586 [details]
Bug 1694927 - Don't allow location APIs to steal focus. r=smaug

Approved for 86.0.1

Comment 26

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-release/rev/4ba95ac768af

Comment 27

[Ryan VanderMeulen [:RyanVM]]

Added to the 86.0.1 relnotes:

Fixed an issue causing windows to gain or lose focus unexpectedly

Comment 28

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Hello! Reproduced the initial issue with Firefox 88.0a1 (20210225215504) on Windows 10x64.
The issue is verified fixed with Firefox 86.0.a1 (20210310152336) on Windows 10x64, macOS 11.2.3 and Ubuntu 18.04. The open window no longer loses focus when clicking the link inside the test case.