1665752 - Additional pair of blur and focus event gets fired while triggering the accesskey shortcut on OOP iframe

Status: RESOLVED FIXED

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

Description

[Edgar Chen [:edgar]]

Attachment: test.html

After triggering the accesskey shortcut, for example, control + option + a on Mac, there is additional pair of blur and focus event gets fired. Like,

onfocus: target: https://bugzilla.mozilla.org/show_bug.cgi?id=1661415
onclick: target: https://bugzilla.mozilla.org/show_bug.cgi?id=1661415
onblur: target: https://bugzilla.mozilla.org/show_bug.cgi?id=1661415
onfocus: target: https://bugzilla.mozilla.org/show_bug.cgi?id=1661415

Where there is only one focus event on non-Fission

onfocus: target: https://bugzilla.mozilla.org/show_bug.cgi?id=1661415
onclick: target: https://bugzilla.mozilla.org/show_bug.cgi?id=1661415

Comment 1

[Edgar Chen [:edgar]]

See
https://bugzilla.mozilla.org/show_bug.cgi?id=1661415#c4
https://bugzilla.mozilla.org/show_bug.cgi?id=1661415#c6
https://bugzilla.mozilla.org/show_bug.cgi?id=1661415#c7

Comment 2

[Edgar Chen [:edgar]]

I also saw similar behavior on tab key navigation in OOP iframe.

Comment 3

[Edgar Chen [:edgar]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=8e33cd0e00cf65093156581530d49c6ef07702c0

Comment 4

[Edgar Chen [:edgar]]

https://treeherder.mozilla.org/#/jobs?repo=try&group_state=expanded&tier=1&revision=b3a150424671c3e615b1ff708ba7521f410811b5

Comment 5

[Edgar Chen [:edgar]]

Attachment: Bug 1665752 - Part 1: Don't expose `aFocusIsOutOfProcess` if the frameLoad acts as boundary;

nsFocusManager::GetFocusedDescendant only returns the focused descendant within
the same browsing context boundary, so we don't expose aFocusIsOutOfProcess
if the frameLoad acts as boundary, either.

Comment 6

[Edgar Chen [:edgar]]

https://treeherder.mozilla.org/#/jobs?repo=try&group_state=expanded&revision=66a6fe1b202d2790cfb914a57b83ecb9a512ff07

I have a WIP that could avoid additional pair of blur and focus events.
But almost all xorigin test on try gets timed out due to the lack of focus event. :(

Comment 7

[Edgar Chen [:edgar]]

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

https://treeherder.mozilla.org/#/jobs?repo=try&group_state=expanded&revision=66a6fe1b202d2790cfb914a57b83ecb9a512ff07

I have a WIP that could avoid additional pair of blur and focus events.
But almost all xorigin test on try gets timed out due to the lack of focus event. :(

What the WIP does is to check mFocusedBrowsingContext in nsFocusManager::SetFocusInner, if the mFocusedBrowsingContext already pointers to embeded browsing context that lives in a different process, then parent window don't need to to anything for the frame-focus-request given that the out-of-process iframe already has the focus. However, mFocusedBrowsingContext seems to not be accurate any more after process switching or navigate happens on focused browsing context.

Comment 8

[Edgar Chen [:edgar]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=ecff24e05ba565bacee03ff79bbb4e0f3ebdf52a

Comment 9

[Edgar Chen [:edgar]]

Attachment: Bug 1665752 - Do not send IPC to request focus if the browsing context already has the focus;

Comment 10

[Edgar Chen [:edgar]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=89985506a5d182cb74b8369c53a691f98e8959b5

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f4242b119e61
Do not send IPC to request focus if the browsing context already has the focus; r=hsivonen

Comment 12

[Dorel Luca [:dluca]]

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