Change in v10.11.1 causes inputs to lose focus on DOM changes

[jcestibariz]

• Check if updating to the latest Preact version resolves the issue (no)

Describe the bug
Up to preact v10.11.0 changes in the DOM did not cause a focused input to lose focus. Starting with v10.11.1 the input loses focus.

To Reproduce

Steps to reproduce the behavior:

1. Check out https://github.com/jcestibariz/bug-preact-focus
2. Notice preact is locked to v10.11.0 which does not contain the bug
3. Run npm i and then npm start
4. In the browser click on the input and press backspace
5. Notice the last "tag" is removed but the input keeps focus.
6. Go back to the console and press Ctrl+C to stop the server
7. Run npm i preact@10.11.1 and then npm start
8. Go back to the browser and repeat step 4
9. Notice now the input loses focus
10. You can also check with the latest version (v10.11.3 as of this moment) the bug is still present

Expected behavior
The input should not lose focus when DOM changes.

[jcestibariz]

I ran a git bisect and looks like the commit that caused this bug is:

284a8b0d969f8ef3a3eeff0107b0104a52f774ad is the first bad commit
commit 284a8b0d969f8ef3a3eeff0107b0104a52f774ad
Author: Jovi De Croock <decroockjovi@gmail.com>
Date:   Thu Sep 29 10:42:24 2022 +0200

    remove _nextDom resetting as it collides with nested fragment switching (#3738)

 src/diff/children.js           | 11 ------
 test/browser/fragments.test.js | 78 +++++++++++++++++++++++++++++++++++++++---
 2 files changed, 73 insertions(+), 16 deletions(-)

I reverted this change on top of the current master (d4089df) and I can confirm that reverting this change fixes the bug. Since I don't have enough knowledge of preact's internals to tell @JoviDeCroock 's intention, I won't submit this revert as the solution.

[developit]

Thanks for doing the bisect @jcestibariz, that's super helpful. My guess is that this is triggering a remount that isn't covered by our tests (which sometimes just assert final tree structure).

[jcestibariz]

Yes, I'm pretty sure the input is removed from the DOM and added back. One of the unit tests (test/browser/fragments.test.js line 240) seems to be checking for the DOM operations queued, in the diff for that commit you can see an additional remove and two appendChild calls were added

[JoviDeCroock]

Reverting it would not be the right course of action as the PR solves an issue with unmounting fragments, dissecting the issue though points at a bigger one 😅 so first off, the reproduction isn't using keys for a changing list of elements, which does hint that these remounts are intended. Going further, when we add the keys, in this reproduction, we can see that the focus is lost when we remove the first element but not the second time around which does point that we are dealing with a matching issue of or dom or vnodes.

PR for reference #3738 - we might need to tweak this to better account for the two cases.

[jcestibariz]

I had missed the key in each "tag" span, sorry about that. I added that and added a third tag. The behaviour didn't change after adding the key, the bug is still reproducible. Notice that removing each of "bar" and "baz" tags the focus is lost. As @JoviDeCroock observed only when the last tag ("foo") is removed the focus stays on the input.

[andrewiggins]

Re: our test suite - we have quite a few tests around maintaining focus on inputs when adding/removing elements around it, but it does not cover removing the element directly before the input. Thanks for finding and reporting this!

Fix incoming, hang tight :)