Cursor blinking in a tab that doesn't have focus after moving the tab to a new window.
Categories
(Core :: DOM: UI Events & Focus Handling, defect, P3)
Tracking
()
People
(Reporter: mhoye, Unassigned)
References
Details
If I drag a gdoc/text-input tab from window A to Window B and drop it, the cursor starts flashing in the Window B document, tricking me into thinking it has focus. When I start typing, though, I'm typing into the address bar back on Window A.
I'm on current nightly, current Win10, and can reproduce arbitrarily.
|
||
Comment 1•5 years ago
|
||
Is this only with GDoc? GDoc seems to implement its own caret handling.
Chrome seems to deal with focus handling differently when dragging tabs, focus is moved out from the content.
(I'm not sure whether this is a Firefox or GDocs issue)
|
Reporter | |
Comment 2•5 years ago
|
||
Nope, I can duplicate this using only Bugzilla. Two nightly windows side by side, drag a bugzilla tab from one to the other, and see the cursor flashing in the add-comment field in the new window, but start typing and the typing hits the window you dragged it out of.
In fact, as I'm typing this right now the cursor is still blinking in the other window's add-comment box.
|
|
||
Comment 3•5 years ago
|
||
Ok, thanks.
hsivonen, since you've been looking into focus handling recently, perhaps you have a hunch.
|
||
Comment 4•5 years ago
|
||
I can reproduce on Windows 10 and macOS Mojave. I can't repro on Ubuntu in a Wayland session.
Most likely BrowserParent::UpdateFocus() doesn't get called or gets called but computes the wrong result.
Leaving myself needinfoed for further investigation.
|
||
Updated•4 years ago
|
|
|
||
Comment 5•4 years ago
|
||
Found bug 1659439 while trying to repro on Linux. (Still can't.)
|
|
||
Comment 6•4 years ago
|
||
(In reply to Henri Sivonen (:hsivonen) from comment #4)
I can reproduce on Windows 10 and macOS Mojave. I can't repro on Ubuntu in a Wayland session.
I can still repro on Windows 10 and macOS Mojave. I can't repro either in an X session or when running on XWayland in a Wayland session. However, I can repro when running natively on Wayland!
Most likely
BrowserParent::UpdateFocus()doesn't get called or gets called but computes the wrong result.
Looking at the symptoms more closely, it looks like BrowserParent::UpdateFocus() is doing OK. I.e. the keyboard event routing is right relative to which window paints an active title bar.
We do have a problem with updating the state affecting how we paint the tab that was dragged elsewhere. I will keep investigating.
|
|
||
Comment 7•4 years ago
|
||
This has been deferred past the Fission Nightly experiment, because the keyboard routing matches what the window title bar activeness state shows.
Description
•