1422687 - Input elements do not work anymore after dragging a tab out of window and putting it back

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, defect, P2)

Description

[Sean Lee [:seanlee][:weilonge]]

STR:
1. Create a new tab.
2. Browser a test page with input elements, e.g. https://luke-chang.github.io/autofill-demo/basic.html
3. Drag the tab out of the window.
4. Drag the tab back to the previous window.
5. The input elements can work as normal.

Actual Behavior:
For Step 5, the input elements can not work any more.

Note:
This can be reproduced on
1. m-c: https://reviewboard-hg.mozilla.org/gecko/rev/989959ce9988e3ac9308c28ac10b5dc87f3b1036
2. FirefoxDevEdition 58.0b8 (64-bit)

Comment 1

[Luke Chang [:lchang] (inactive)]

I can reproduced this issue even if I disabled the Form Autofill system add-on entirely (not only disabled its feature in Preferences but also prevent the system add-on from running in the beginning). It appears unrelated to Form Autofill, so I think DOM component might be more appropriate to this bug.

Comment 2

[Luke Chang [:lchang] (inactive)]

I can reproduce this bug on Fx57 as well. BTW, this bug can recover by blurring and re-focusing the tab.

Comment 3

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

Samael/Jessica, do you have ideas of what may cause this issue?

Comment 4

[Jessica Jong [:jessica] (inactive)]

I can reproduce this on Mac but not on Linux Ubuntu.
The inputs are still workable, you can type normally when clicking on it, the document.activeElement is also the input, it just doesn't show the focus border and the caret. So I guess it's something with the focus?
If it's not urgent, I can dig deeper later, keeping the NI flag for tracking.

Comment 5

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

Luke told me this isn't a blocker to them. :)

Comment 6

[Jessica Jong [:jessica] (inactive)]

I look at this today and here are some findings:

- When the tab is dragged back to the windows, clicking on the input produces this log:

> D/Focus <<SetFocus begin>>
> D/Focus <<SetFocus end>>
> D/Focus <<SetFocus begin>>
> D/Focus Shift Focus: input
> D/Focus  Flags: 1002 Current Window: 0x0 New Window: 0x11bc1e220 Current Element: 0x0
> D/Focus  In Active Window: 0 In Focused Window: 0 SendFocus: 0
> D/Focus <<SetFocus end>>

The focus is not sent to the input element because it is not in the active window.

- Comparing with Ubuntu, which does not have this issue, when the tab is dragged back to the windows, we see:

> D/Focus <<SetFocus begin>>
> D/Focus Shift Focus: browser
> D/Focus  Flags: 2 Current Window: 0x7fe2cad6f770 New Window: 0x7fe2e0bf07f0 Current Element: (nil)
> D/Focus  In Active Window: 0 In Focused Window: 0 SendFocus: 0
> D/Focus <<SetFocus end>>
> D/Focus <<SetFocus begin>>
> D/Focus Shift Focus: window
> D/Focus  Flags: 2 Current Window: 0x7fe2cad6f770 New Window: 0x7fe2cad6f770 Current Element: (nil)
> D/Focus  In Active Window: 1 In Focused Window: 1 SendFocus: 1
> D/Focus <<Blur begin>>
> D/Focus Element (none) has been blurred
> D/Focus Update Caret: 0 1
> D/Focus <<Focus begin>>
> D/Focus Element window has been focused
> D/Focus  from window
> D/Focus  [Newdoc: 0 FocusChanged: 1 Raised: 0 Flags: 2]
> D/Focus Update Caret: 1 0
> D/Focus <<SetFocus end>>

In OS X, "Shift Focus: window" part does not happen, so the active window is not updated.
And the "Shift Focus: window" part in Ubuntu, _seems_ to be caused by:
https://searchfox.org/mozilla-central/rev/b24e6342d744c5a83fab5c15972e11eeb69d68e6/toolkit/content/widgets/popup.xml#346
But I'm not sure why `popuphidden` was not fired in OS X in this case.

Comment 7

[Andrei Purice]

Marking this as Resolved > Worksforme since the issue is no longer reproducible on the latest versions of Firefox Nightly 96.0a1 (2021-11-01), beta 94.0 or release 93.0 on Windows 10.
If anyone is still able to reproduce the issue please re-open it or file a new one.