1707944 - form field loses focus when moving tab to new window with browser.newtabpage.enabled set to false

Status: NEW

(Core :: Widget: Cocoa, defect, P3)

Description

[Dan Black]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:88.0) Gecko/20100101 Firefox/88.0

Steps to reproduce:

Start with a window with multiple tabs. The tab I'm on has a form -- for example, a login form. I have focus on one of the fields for typing. (It's a text field. I'm guessing it's true of other fields, but haven't verified.) I move the tab out of that window, to create a new window.

[I'm using the latest Firefox -- 88.0 -- on a Mac.]

Actual results:

The form field loses focus as far as typing is concerned. The styling and typing cursor still indicate that field has focus, but I can't type without clicking in that field again. Or I can [tab] to change focus, but I'm not sure where the focus is -- probably on the overall window -- because it has to go through the address bar and all my toolbar bookmarks and things before getting back to the actual form.

Note that it works as expected when moving the tab to another existing window with other tabs. But it loses focus when you move that tab out to create a new window. In fact, you can even move the tab to a new window, it loses focus for typing; then move the tab back to the original window or even a different existing window, and you regain typing focus. Move the tab out to a new window, and it loses typing focus for that form field again.

I first noticed this many months (maybe even over a year) ago, so it's not a very recent bug, but I don't think it had this bug several years ago.

Expected results:

Typing focus should have remained on the field I was typing in.

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::DOM: UI Events & Focus Handling' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

I can't reproduce on Linux nor Windows.
My testcase was:
Open a new tab
load data:text/html,<textarea>
drag the tab out from its window so that a new window is created
Continue typing

Smell like some MacOS specific focus issue.

Comment 3

[Stephen A Pohl [:spohl]]

I haven't been able to reproduce this so far. Dan, are you able to reproduce with the simplified test case that :smaug posted in comment 2?

data:text/html,<textarea>

Comment 4

[Dan Black]

Yes, I'm able to reproduce the problem consistently.

I had only tried it in a text input field, not a textarea, but I just tested, and it does it in textareas, too. Also select boxes -- I just tested where you focus on a select box and type to select the option. So this is probably happening with any form field, and possibly other (non-form) elements, since I think it's basically just moving the focus to some part of the window outside the html frame.

It's entirely possible the problem only shows up on MacOS, but it's consistent, has been happening for at least several months/versions, and I'm fairly sure it has only been a problem for several months or possibly a couple years. And it still regains keyboard focus when you join it with another existing window with other tabs -- even if that's just another newly created window with one other empty tab.

I can do a screen recording and add it somewhere if that would help.

I just wrote the following simple html form, and it has the problem on all three of these form elements.

I also included a javascript to track what object has focus, and it doesn't change when you move the tab out to its own new window, so at least the javascript engine still thinks that form input has focus.

<html>

 <head>
  <title>test</title>
  <script language="javascript">
   function reportFocusedElement()
   {
    document.getElementById("focus-element").innerHTML = document.activeElement;
   }
  </script>
 </head>

 <body onload="setInterval(reportFocusedElement, 1000);">

  <p>current focused element: <span id="focus-element"></span></p>

  <form>
   <p><input type="text" name="test1"></p>
   <p><textarea name="test2"></textarea></p>
   <p>
    <select name="test3">
     <option value="test3a">a test</option>
     <option value="test3b">b test</option>
     <option value="test3c">c test</option>
     <option value="test3d">d test</option>
     <option value="test3e">e test</option>
    </select>
   </p>
  </form>

 </body>
</html>

Comment 5

[Stephen A Pohl [:spohl]]

I should have probably clarified that I tried to reproduce this on macOS 11.4 Beta with various versions of Firefox. Are you able to reproduce in safe mode and/or a new profile? Do any of the troubleshooting steps help?

Comment 6

[Dan Black]

Safe mode didn't fix it, but a new profile did. So I figured it might be some of my config options, so I dug through the "tab" options that I have non-default settings, and I'm fairly sure I found it.

If you set browser.newtabpage.enabled to false, that seems to trigger the problem.

On both my new test profile and my old profile, setting it to false causes the problem, and setting it back to true "fixes" it.

Assuming you can reproduce the problem with that setting, does that qualify as a bug that should be fixed?

Comment 7

[Stephen A Pohl [:spohl]]

Thank you for the additional info! Yes, this is a valid bug and I am now able to reproduce the issue.

Comment 8

[Dan Black]

Out of curiosity, do you (or does anyone else) know if this does also happen on non-Macs?