1824155 - Accessible Caret shows on both iframes

Status: VERIFIED FIXED

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

Description

[Makoto Kato [:m_kato]]

Attachment: screen shot

Environment

• Firefox Nightly or GeckoView Example with Fission (./mach run --enable-fission)
• Android
• Windows 10 tablet mode.

Step

1. Run with Fission
2. Open https://wontfix.net/bugs/iframe1.html. (all iframe are OOP)
3. Select "area" text in 3rd iframe by long tap
4. Select "foo" text in 2nd iframe by long tap

Result

2nd iframe and 3rd iframe show accessible caret. If not fission (or https://wontfix.dev/bugs/iframe1.html), it isn't show on both. See attached screen shot.

Expected Result

Don't show 2 accessible carets at same time.

Notes

After this, when moving accessible caret, It seems to hit this assertion.

MOZ_Assert: Assertion failure: GetCaretMode() != CaretMode::None, at /builds/worker/checkouts/gecko/layout/base/AccessibleCaretManager.cpp:510

Comment 1

[[:owlish] 🦉 PST]

Hi Edgar, the Firefox Android is preparing to run Fission related experiments staring around the end of Q3, and would like to get any remaining blocking bugs addressed by 128 Release. Could you help triage and fix this issue?

Comment 2

[Edgar Chen [:edgar]]

Attachment: focus.html

I think this is a focus bug,

STR:

1. click input in first iframe.
2. focus moves to the first iframe.
3. click second iframe (not on input element).

Actual behavior:
There is no blur event fired on first iframe.

Expected behavior:
blur event is fired on first iframe.

Comment 3

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Forwarding the needinfo to me that I need to explore resourcing plan on the team.

Comment 4

[Makoto Kato [:m_kato]]

I guess that we have to handle blur of iframe window on Accessible Caret. But I don't know we can receive something event like blur of OOP frame.

Ting-Yu, do you have an idea to to fix this?

Comment 5

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

AccessibleCaret already handles blur event by hiding the carets in AccessibleCaretManager::OnBlur(). Per comment 2, we don't fire blur event on <input> when switching focus to a different iframe. I can also reproduce it in desktop. Note that if I repeat the step 3 again, the blur event does fire.

Unfortunately, I'm not familiar with focus handling and blur events, so I don't have any idea to fix this bug. But I believe if the blur events are fired correctly, AccessibleCaret should be able to react on it.

Comment 6

[Edgar Chen [:edgar]]

(In reply to Edgar Chen [:edgar] from comment #2)

3. click second iframe (not on input element).

When user clicks on the iframe body, nsFocusManager::SetFocusedWindow() is called in EventStateManager::PostHandleEvent() to switch focus to the target window. Since it is an OOP iframe, we cannot get the frame element (that lives in different process). So we end up at https://searchfox.org/mozilla-central/rev/8e885f04a0a4ff6d64ea59741c10d9b8e45d9ff8/dom/base/nsFocusManager.cpp#413-421. From the code comment, those code are for top-level window, but the target frame isn't a top-level window.

Compare to e10s, it runs https://searchfox.org/mozilla-central/rev/8e885f04a0a4ff6d64ea59741c10d9b8e45d9ff8/dom/base/nsFocusManager.cpp#409-411 instead, which will trigger blur steps in https://searchfox.org/mozilla-central/rev/8e885f04a0a4ff6d64ea59741c10d9b8e45d9ff8/dom/base/nsFocusManager.cpp#1784.

Triggering blur steps for OOP iframe, something like https://hg.mozilla.org/try/rev/7d44e47b09b38400495a778b7dd5543348b67e92#l1.19, can make the AccessibleCaret behave as expected. But I am not sure if it is sufficient or even correct from focus handling point of view. There are some failures on try result, https://treeherder.mozilla.org/jobs?repo=try&revision=6013e04e41fb5b252402f9ddd25a50e343dbe64b&group_state=expanded, haven't checked those failures, either.

Comment 7

[Sean Feng [:sefeng]]

I am working on this

Comment 8

[Sean Feng [:sefeng]]

Attachment: Bug 1824155 - Ensure focused browsing context is blurred when an OOP window is focused r=#dom-core,edgar

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c1fdd0149a3b
Ensure focused browsing context is blurred when an OOP window is focused r=edgar,dom-core

Comment 10

[Serban Stanca [:SerbanS]]

Backed out for causing linting opt failures.

• Backout link
• Push with failures
• Failure Log
• Failure line: TEST-UNEXPECTED-ERROR | /builds/worker/checkouts/gecko/testing/web-platform/tests/focus/focus-event-after-switching-iframes.sub.html:0 | Missing <script src='/resources/testdriver-vendor.js'> (MISSING-TESTDRIVER-VENDOR)

Comment 11

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/46519 for changes under testing/web-platform/tests

Comment 12

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR was closed without merging

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/24f2a6791095
Ensure focused browsing context is blurred when an OOP window is focused r=edgar,dom-core

Comment 14

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 15

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/24f2a6791095

Comment 16

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

Issue is reproducible on a 2024-05-28 Nightly build on Windows 10, using the STR and testcase from Comment 2.
Verified as fixed on Firefox 128.0b2 and Firefox Nightly 129.0a1 on Windows 10, Ubuntu 22, macOS 14.