Closed Bug 1659383 Opened 4 years ago Closed 4 years ago

Tab occasionally steals focus

Categories

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

Product:
Core
Component:
DOM: UI Events & Focus Handling
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
86 Branch
Project Flags:
Fission Milestone M7
Tracking Flags:
Tracking Status
firefox86 --- fixed

People

(Reporter: annevk, Assigned: hsivonen)

References

(Blocks 2 open bugs,
URL
)

Details

Attachments

(1 file)

Bug 1659383 - Check if focus() is allowed even when Window_Binding::focus() delegates to BrowsingContext::Focus().
48 bytes, text/x-phabricator-request
Details | Review

When I have https://www.nintendo.de/Spiele/Nintendo-Switch-Download-Software/The-Talos-Principle-Deluxe-Edition-1695266.html open (I'm also logged in, but haven't really interacted with it that I recall) it seems to occasionally steal focus. It's an [F 4404, 72719, 6183, 6186, 4525] tab.

Cannot figure out precise steps to reproduce, but it happened twice now and I'm positive I didn't do any other action that might cause a tab switch.

Flags: needinfo?(hsivonen)

I left this page open for a while in a background tab in a debug build with the build on the background in the OS, but when I checked back, it was still in a background tab. I wonder if the window needs to be the frontmost window in the OS for this to happen.

I've had this happen with https://www.nintendo.co.uk/Super-Mario-Bros-35th-Anniversary-hub/Super-Mario-Bros-35th-Anniversary-Prize-Days-Day-1-1876606.html too. (Less processes involved there it seems and no overlap with the tab focus got stolen from.)

If the tab is in the background, how does the focus stealing manifest? Does the tab become the active tab without clicking the tab title?

Flags: needinfo?(hsivonen) → needinfo?(annevk)

Yeah, while interacting with another tab, sometimes even when typing in a textarea, iirc, it would suddenly make that tab the active tab as if you had accidentally clicked it with the mouse.

Flags: needinfo?(annevk)

(In reply to Anne (:annevk) from comment #2)

I've had this happen with https://www.nintendo.co.uk/Super-Mario-Bros-35th-Anniversary-hub/Super-Mario-Bros-35th-Anniversary-Prize-Days-Day-1-1876606.html too. (Less processes involved there it seems and no overlap with the tab focus got stolen from.)

I've now witnessed this on that page when logged into a Nintendo account.

Assignee: nobody → hsivonen
Blocks: fission-dogfooding, fission-focus
Severity: -- → S2
Status: NEW → ASSIGNED
Fission Milestone: --- → M7
Priority: -- → P2

It looks like it's a matter of the page calling .focus() on a window object whose C++ delegate is BrowsingContext rather than nsGlobalWindowInner. In the latter case, we call FocusOuter which runs checks to see if the focusing is allowed. In the former case we just go ahead and assume that the focusing is allowed.

We need to duplicate some of those permission checks on the code path beginning from BrowsingContext::Focus.

Pushed by hsivonen@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/d2c7360e9d01 Check if focus() is allowed even when Window_Binding::focus() delegates to BrowsingContext::Focus(). r=nika
Failed to create upstream wpt PR due to merge conflicts. This requires fixup from a wpt sync admin.

Backed out for failures on iframe-focuses-parent-different-site.html

backout: https://hg.mozilla.org/integration/autoland/rev/70b4a36723e904470b52d837a0661428bf14e3c9

push: https://treeherder.mozilla.org/jobs?repo=autoland&revision=d2c7360e9d010e61e0a1060e6e74fc5afb2fd0e4&group_state=expanded

push where tier 1 failures appeared: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&revision=59bc879e3bc635c14b5dde45bd2d68d74da9dde1&searchStr=wpt13&selectedTaskRun=awhOgm9TTquH7Ur0kawpvQ.0

failure log: https://treeherder.mozilla.org/logviewer?job_id=326995670&repo=autoland&lineNumber=3285

[task 2021-01-18T09:43:55.538Z] 09:43:55 INFO - TEST-START | /focus/iframe-focuses-parent-different-site.html
[task 2021-01-18T09:43:55.543Z] 09:43:55 INFO - Closing window 75
[task 2021-01-18T09:44:35.948Z] 09:44:35 INFO - TEST-UNEXPECTED-TIMEOUT | /focus/iframe-focuses-parent-different-site.html | expected OK
[task 2021-01-18T09:44:35.948Z] 09:44:35 INFO - TEST-INFO took 40410ms
[task 2021-01-18T09:44:36.329Z] 09:44:36 INFO - STDOUT: cleanup aborted: Unable to remount device
[task 2021-01-18T09:44:36.459Z] 09:44:36 INFO - STDOUT: cleanup aborted: Unable to remount device
[task 2021-01-18T09:44:36.460Z] 09:44:36 INFO - Closing logging queue

Flags: needinfo?(hsivonen)

Strange. Things were OK in the try run from comment 11.

Flags: needinfo?(hsivonen)

(In reply to Henri Sivonen (:hsivonen) from comment #15)

Strange. Things were OK in the try run from comment 11.

The failures have appeared on Android 7.0 x86-64

Blocks: 1687280
Pushed by hsivonen@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/c7f363ff3c4f Check if focus() is allowed even when Window_Binding::focus() delegates to BrowsingContext::Focus(). r=nika
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/27225 for changes under testing/web-platform/tests

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

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
status-firefox86: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 86 Branch

Thanks. I'll take a look over in bug 1677899 .

Flags: needinfo?(hsivonen)
Upstream PR merged by moz-wptsync-bot
Blocks: 1683277
Regressions: 1691214
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: