1943053 - pinterest.com - Keyboard overlaps the chat box when trying to send messages

Status: NEW

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

Description

[Calin Tanase]

Attachment: message FF vs Chrome.mp4

Environment:
Operating system: OnePlus 6 A6000 (Android 11)
Firefox version: 134/136

Preconditions:

• Must be logged in
• Clean profile

Steps to reproduce:

1. Go to https://ro.pinterest.com/inbox
2. Access a contact from the list (if there are none, tap on "New message" and search for someone randomly).
3. Tap on the chat box.

Expected Behavior:
Keyboard appears below the chat box.

Actual Behavior:
Keyboard overlaps the chat box, scrolling is needed in order to make it visible.

Notes:

• Reproducible on the latest Firefox Release and Nightly
• Reproducible regardless of the ETP setting
• Works as expected using Chrome
• Issue found during WebCompat team [Top100] websites testing

Comment 1

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

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

Comment 2

[Daniel Holbert [:dholbert] (PTO until 2/24)]

(In reply to Calin Tanase from comment #0)

Steps to reproduce:

1. Go to https://ro.pinterest.com/inbox

I can reproduce, using my pinterest account and https://www.pinterest.com/inbox (i.e. this isn't ro.-locale-specific)

Comment 3

[Daniel Holbert [:dholbert] (PTO until 2/24)]

Our actual-results here look basically the same as we did pre-bug-1884807 / bug 1916002 (i.e. the pre-"interactive-widget resizes-visual" behavior).

botond/hiro, do you know what's going on here and why we're not shifting the whole viewport upwards to dodge the keyboard?

Comment 4

[Hiroyuki Ikezoe (:hiro)]

It's quite hard to tell without diagnosing. I created an account on pinterest and try to start a chat with "Mozilla" account I found, but it doesn't work at all. There's no "Type a message" input box on my end.

Anyways, I am moderately sure the site does something special for Chrome. Maybe the site is using VirtualKeyboard API to move the input box into the visual viewport. That's said, Safari hasn't yet implemented VirtualKeyboardAPI, so the site should not work with the way on Safari.

(NOTE: I personally prefer a declarative way to move this kind of input element into the view)

Two questions;

1. Whether the site specifies interative-widget or not
2. what's the position style value of the input box?

I guess the position style is fixed but the top (or bottom) is changed when the keyboard appears on Chrome.

Comment 5

[Botond Ballo [:botond]]

I am able to reproduce this.

However, the symptoms here are a bit different from the ones we expect bug 1884807 / bug 1916002 to fix. Those bugs addressed cases where, after the keyboard comes up, the input element you're typing into is hidden by the keyboard and cannot be scrolled into view.

On this page, the input element can be scrolled into view, it just doesn't happen automatically (for some still-to-be-diagnosed reason).

(I think that also means this bug does not merit S2 severity: manually scrolling the input field into view is a readily apparent and available workaround.)

Comment 6

[Botond Ballo [:botond]]

(In reply to Botond Ballo [:botond] from comment #5)

On this page, the input element can be scrolled into view, it just doesn't happen automatically (for some still-to-be-diagnosed reason).

The reason does seem to be related to bug 1916002: I tried adding interactive-widget=resizes-content to the page's meta viewport tag, and with that the input element is successfully scrolled into view.

While I don't know exactly how resizes-visual breaks this, it's at least plausible that it does: with resizes-visual, the "scroll into view" operation takes a different codepath (scroll visual viewport within layout viewport) than with resizes-content (scroll layout viewport).

I'm going to mark this as a regression from bug 1916002.

Comment 7

[Hiroyuki Ikezoe (:hiro)]

Attachment: A test case where scrollIntoView works

(In reply to Botond Ballo [:botond] from comment #6)

(In reply to Botond Ballo [:botond] from comment #5)

On this page, the input element can be scrolled into view, it just doesn't happen automatically (for some still-to-be-diagnosed reason).

Given that the input element can be scrolled into view, its position style is not fixed, I suppose.

While I don't know exactly how resizes-visual breaks this, it's at least plausible that it does: with resizes-visual, the "scroll into view" operation takes a different codepath (scroll visual viewport within layout viewport) than with resizes-content (scroll layout viewport).

Attaching HTML is an example to see an input element is scrolled into view when the keyboard appears. So it should basically work, it may be a race condition.

Comment 8

[Botond Ballo [:botond]]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #7)

Given that the input element can be scrolled into view, its position style is not fixed, I suppose.

It seems to be inside a position: absolute div with bottom: 0.

Comment 9

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

Set release status flags based on info from the regressing bug 1916002

Comment 10

[Botond Ballo [:botond]]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #7)

Attaching HTML is an example to see an input element is scrolled into view when the keyboard appears. So it should basically work, it may be a race condition.

On this working page, when the scroll happens, I see in the logs:

[GPU 22844: WRSceneBuilder#2]: D/apz.controller 7dffdc3800 updating visual scroll offset from (0,0) to (0,312.833) (updateType 1)

I think that suggests the scrolling is accomplished by this ScrollContentIntoView call which ultimately requests a visual viewport scroll here.

On the pinterest page, I see no such log message.

Comment 11

[Hiroyuki Ikezoe (:hiro)]

Attachment: A possible replicated test case

Okay, this test case is probably a test case for the site.

The input box is inside a position: absolute: bottom: 0 box inside a position: fixed; bottom: 0 element.

And I guess it's a race condition, I can reliable see the problem on a nightly on my pixel 3, but I can't see the problem on Firefox 134 on the same phone.

Maybe it's time to refactor our zoom-to-focused-input to do all works in APZ rather than scrollIntoView on the main-thread.

Alternatively we can defer triggering the scrollIntoView until we know for sure that the visual viewport has been resized by the keyboard.

Comment 12

[Botond Ballo [:botond]]

The test case from comment 11 works correctly for me, even though the pinterest page does not, so I'm not sure that it's affected by the same issue.

Comment 13

[Hiroyuki Ikezoe (:hiro)]

At least on my end, the test case is regressed in this range; https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6f928a37b801026db617dc5dedfe5a4f9bc88f8c&tochange=b6fe6098a8bbf74edca23103c6756be13d238378 . (mozregression got stuck there).

I am pretty sure the culprit is bug 1931225.

Comment 14

[Botond Ballo [:botond]]

By the way, in case it helps repro the issue on the pinterest site, the exact steps to get to the page with the input box are:

• Log into pinterest.com
• It will ask if you want to open the app, tap "Continue in browser"
• In the bottom navigation bar, tap "Inbox"
• Scroll up to the top and tap on "Inbox"
• Tap "New message"
• Tap the "Search by name or email" input field (note: this is not the buggy one)
• Tap a random name and select an arbitrary account
• Tap next
• Finally, tap the input field at the bottom of the page

Comment 15

[Botond Ballo [:botond]]

I did confirm that the reason ZoomToRect() does not perform scrolling is because of the early exit added in bug 1931225.

It remains to be understood why the ScrollContentIntoView() call does not perform scrolling.

Comment 16

[Botond Ballo [:botond]]

I did a bit more investigation:

• Though I didn't realize this initially, one of the ancestors of the input element is in fact position: fixed, i.e. the page structure is quite similar to the one in the reduced testcase.
  • This means that the loop in PresShell::ScrollFrameIntoView() bypasses the root scroll frame.
    • This seems like a deficiency in ScrollFrameIntoView(). At least the ScrollToVisual() call should happen for fixed elements as well, since we may need to scroll the visual viewport within the layout viewport to bring a fixed element into the visual viewport.
• I can in fact reproduce the bug on the reduced testcase in GeckoView Example.
• In Fenix, I cannot reproduce the bug on the reduced testcase. A brief look suggests that in spite of the interactive-widget=resizes-visual, the layout viewport is being resized as well; I'm not quite sure why.

Comment 17

[Hiroyuki Ikezoe (:hiro)]

(In reply to Botond Ballo [:botond] from comment #16)

• Though I didn't realize this initially, one of the ancestors of the input element is in fact position: fixed, i.e. the page structure is quite similar to the one in the reduced testcase.
  • This means that the loop in PresShell::ScrollFrameIntoView() bypasses the root scroll frame.

Yeah, that's an important part of this bug. We do scroll visually inside ScrollFrameIntoView which is invoked in the loop. So we don't scroll visually.

Comment 18

[Botond Ballo [:botond]]

Removing needsdiagnosis flag as I believe we now have a complete diagnosis, with a platform-bug on file at bug 1943865.

Comment 19

[Daniel Holbert [:dholbert] (PTO until 2/24)]

I hit what looks like the same issue just now at https://www.kqed.org/verify BTW. When I focus the email field, the keyboard covers it up in Firefox Nightly, but not in Chrome (on Android 15).

Comment 20

[Daniel Holbert [:dholbert] (PTO until 2/24)]

Same issue possibly with the support chatbot text entry box on https://foodlion.com/contact

(Tap the textbox, and the keyboard covers it up. In Chrome it slides up when the keyboard appears.)