Closed
Bug 1674702
Opened 4 years ago
Closed 4 years ago
Additional pair of blur and focus event gets fired while calling window.focus() on OOP iframe
Categories
(Core :: DOM: UI Events & Focus Handling, defect, P3)
Core
DOM: UI Events & Focus Handling
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox85 | --- | fixed |
People
(Reporter: edgar, Assigned: edgar)
References
(Blocks 1 open bug)
Details
Attachments
(1 file, 2 obsolete files)
|
(deleted),
text/x-phabricator-request
|
Details |
STR:
- enable fission
- load https://codepen.io/edgarchen-the-decoder/full/xxOjjGX
- click
window.focus()button to trigger window.focus() call
Expected result:
No additional blur and focus event.
Actual result:
Additional blur and focus event gets fired.
|
Assignee | |
Updated•4 years ago
|
Blocks: fission-focus
|
|
Assignee | |
Comment 1•4 years ago
|
||
|
||
Updated•4 years ago
|
Assignee: nobody → echen
Status: NEW → ASSIGNED
Fission Milestone: --- → M7
|
|
Assignee | |
Comment 2•4 years ago
|
||
One case of the additional focus event gets fired is from nsFocusManager::Focus call in nsFocusManager::WindowRaised where we always pass true as aNewDocument.
|
|
Assignee | |
Comment 3•4 years ago
|
||
|
|
Assignee | |
Comment 4•4 years ago
|
||
|
|
Assignee | |
Comment 5•4 years ago
|
||
Depends on D96719
|
|
Assignee | |
Comment 6•4 years ago
|
||
(Note to myself: rebase over bug 1618639)
|
|
Assignee | |
Comment 7•4 years ago
|
||
|
|
Assignee | |
Comment 8•4 years ago
|
||
I should update what I found, so basically I found following things that we should think about how to handle them,
- comment #2, this is handled in bug 1674743.
- Blur will be always redirected to
focusedBrowsingContext's process iffocusedBrowsingContextis in other process, this will lead to an unnecessary blur action onfocusedBrowsingContext's process, this is why we see additional blur events on OOP iframe for this bug. And it doesn't run Blur steps in current process, I guess we should? At least for https://searchfox.org/mozilla-central/rev/96e2c6e14998f38e419850d55d8a3d32a3fc244a/dom/base/nsFocusManager.cpp#2085-2088, but not sure if there are other possible cases. - Calling
SetFocusedWindowInternalwill also updatefocusedBrowsingContext, this could trigger unnecessary updating, I see one case thatfocusedBrowsingContextbeing updated to the framer, so that OOP iframe think it should run focus steps again.
|
|
Assignee | |
Comment 9•4 years ago
|
||
|
||
Updated•4 years ago
|
Attachment #9187160 -
Attachment is obsolete: true
|
|
||
Updated•4 years ago
|
Attachment #9187161 -
Attachment is obsolete: true
|
|
Assignee | |
Comment 10•4 years ago
|
||
|
|
Assignee | |
Comment 11•4 years ago
|
||
This suppress unnecessary blur and focus actions in the framer, we would need
to find a way to notify framer that the focus has moved to OOP iframe to
dispatch corresponding blur event, see bug 1677474.
|
||
Comment 12•4 years ago
|
||
Pushed by echen@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/15ceb99908ca
Do not bounce IPC message to framer if focus is handled synchronously in OOP iframe; r=hsivonen
Failed to create upstream wpt PR due to merge conflicts. This requires fixup from a wpt sync admin.
|
||
Comment 14•4 years ago
|
||
| bugherder | ||
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
status-firefox85:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 85 Branch
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/26977 for changes under testing/web-platform/tests
Upstream PR merged by moz-wptsync-bot
You need to log in
before you can comment on or make changes to this bug.
Description
•