1929516 - www.lootjestrekken.nl - Keyboard disappears when it is triggered

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect, P2)

Description

[Raul Bucata]

Environment:
Operating system: Android 13
Firefox version: Firefox Mobile 133.0

Steps to reproduce:

1. Navigate to: https://www.lootjestrekken.nl/my-wish-lists/edit/BYkeR8R1jNNO-HqFdQpaig-/ElfLT2ti-zz0T0V94Qz0fA-/gcjIRyooy3nYyMKAIwXfAA-
2. Tap inside the search field "Type your gift wishes here"
3. Observe

Expected Behavior:
The keyboard is triggered and stays fixed

Actual Behavior::
The keyboard disappears once it is triggered

Notes:

• Reproduces regardless of the status of ETP
• Reproduces in firefox-nightly, and firefox-release
• Does not reproduce in chrome

Created from https://github.com/webcompat/web-bugs/issues/143666

Comment 1

[Raul Bucata]

Attachment: 20241106_115758.mp4

Comment 2

[Sean Feng [:sefeng]]

Looks like this relates to how the site handles scroll events, still looking

Comment 3

[Sean Feng [:sefeng]]

So the site has this handler that listens to the scroll event

handleScroll() {
    < some other code, not important> 

    if (this.searchHasFocus && !this.ignoreScroll) {
        e.clearFocus();
    }
    < some other code, not important> 
}

When the user first clicks the <input>, this site will run window.scroll (I think it's in its focus event handler for that <input>) to do a scroll, so it expects the above event handler to run once, and that e.clearFocus() shouldn't be executed at the given time. And this is exactly what happens in Chrome.

However, in Firefox, we dispatch two scroll events. Not only the first one triggered by window.scroll, there's another one triggered by APZ? The callstack is https://pastebin.com/raw/LEiZKfZw

So the above scroll event handler will run twice, and it thinks the second scroll event is triggered by the user hence e.clearFocus(), so the keyboard disappears.

Not sure if this is platform-bug or site bug. Botond, do you know what's going on with the second scroll event?

Comment 4

[Botond Ballo [:botond]]

The call stack from comment 3 is the codepath we would expect to see if there is scrolling triggered by the user (e.g. with a touch drag).

In this case, it sounds like the steps to reproduce do not involve scrolling by the user, so there's no obvious reason why the codepath should run. We need to trace the origin of this scroll further back into compositor code to understand why it does.

Adding [apz-needsdiagnosis] tag for further investigation.

Comment 5

[Sean Feng [:sefeng]]

Thanks Botond.

Yeah, I simply clicked the <input> without doing any scrolling. I'll take this as a platform- bug for now.

I have the setup, let me know if you want me to provide anything.

Comment 6

[Botond Ballo [:botond]]

(In reply to Sean Feng [:sefeng] from comment #5)

I have the setup, let me know if you want me to provide anything.

If you're able to get some logs, as described in this thread, with the following logging modules enabled, that would be great:

apz.controller:4,apz.inputqueue:5,apz.inputstate:5,apz.manager:4,apz.helper:4,apz.eventstate:4

Comment 7

[Hiroyuki Ikezoe (:hiro)]

My wild guess is that, if there are two scroll events, it's probably caused by our scroll position rounding/pixel alignment issue. I saw a redundant scroll event in a different bug.

Comment 8

[Hiroyuki Ikezoe (:hiro)]

I can't reproduce on GeckoView example or on Fenix either on Android emulator 7.0.

Comment 9

[Sean Feng [:sefeng]]

Botond, I got a profile with all those loggings https://share.firefox.dev/4es69ON . Let me know if you need more things

Hiro: I reproduced it on a Samsung S23.

Comment 10

[Hiroyuki Ikezoe (:hiro)]

Oh wait wait. It's scroll event, not scrollend? If a single scroll operation is smooth one, then multiple scroll events can happen. It's natural.

But if multiple scroll events on the same target happened in a single refresh driver tick, that's a bug.

Comment 11

[Hiroyuki Ikezoe (:hiro)]

I am moderately sure that the scroll event is triggered by our zoom-to-focused-input machinery. Setting "apz.zoom-to-focused-input.enabled" to false will solve the issue.

That's said, I thinks a problem is the window.scroll call in the site, on Firefox, it does window.scroll(0,0), or something like that? I can see the sites scrolls up when I tap on the input element, but I can't see it on Chrome. So a question here is why the scroll operation doesn't happen on Chrome. (Or on Chrome, the scroll destination is not close to zero).

Comment 12

[Sean Feng [:sefeng]]

Hey Hiro, I can confirm that setting apz.zoom-to-focused-input.enabled fixes this issue.

re window.scroll, I don't think it does a window.scroll(0, 0), I see it's a window.scroll(0, 115) on my phone.

The actual code is

        scrollToSearch() {
          let t = this.$refs.giftfinder.$refs['commands-placeholder'].getBoundingClientRect(),
          e = parseInt(t.top) + parseInt(window.pageYOffset);
          window.pageYOffset != e &&
          (
            this.ignoreScroll = this.ignoreScroll ? this.ignoreScroll : e,
            window.scroll(0, e),
            this.deviceWindowState.scrollPosition = 0
          );
          var i = this;
          window.setTimeout((function () {
            i.ignoreScroll = null,
            i.sizeWishlist()
          }), 300)

I also see the same scroll being executed in Chrome. And the site expects this to happen, and their scroll event handler won't clear the focus for this scroll. It's the second scroll that happens after this one in Firefox. Maybe we shouldn't dispatch a scroll event when the user is focusing an input?

Comment 13

[Hiroyuki Ikezoe (:hiro)]

I am not yet sure there are multiple causes of the scroll event or not, but I found a cause in APZ, I filed bug 1931225.

Comment 14

[BugBot [:suhaib / :marco/ :calixte]]

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.

Comment 15

[Hiroyuki Ikezoe (:hiro)]

Sean, would you mind trying this build to see whether this bug is fixed on the build or not? The build is including the fix for bug 1931225, I hope it eliminates the redundant scroll event. Thanks!

Comment 16

[Sean Feng [:sefeng]]

Thanks Hiro, I can confirm that build fixes this

Comment 17

[Hiroyuki Ikezoe (:hiro)]

A new nightly build including bug 1931225 has been released via Google Play Store.

Raul, would you mind trying the new nightly to see whether this bug is fixed? Thanks!

Comment 18

[Raul Bucata]

This seems to be fixed on the latest Nightly build

Tested with:

Browser / Version: Firefox Nightly 135.0a1 (2016059175-🦎135.0a1-20241130092829🦎)
Operating System: Oppo Find X5 (Android 13) - 1080 x 2400 pixels, 20:9 ratio (~402 ppi density)

Comment 19

[Hiroyuki Ikezoe (:hiro)]

Thanks!