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]]

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

Comment 2

[Daniel Holbert [:dholbert]]

(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]]

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]]

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]]

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]]

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.)

Comment 21

[Daniel Holbert [:dholbert]]

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

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

bug 1943865 has been fixed, but I can still reproduce a more limited version of this bug in a Pinterest chat page in Nightly.

The remaining issue reproduces if...
(a) you have the dynamic toolbar enabled (as it is by default)
(b) the dynamic toolbar is visible (i.e. you haven't scrolled it away) when you tap the textfield

Under these circumstances: when you tap the "Type a message" textfield and the keyboard appears, it's got the dynamic toolbar still-present just above the keyboard, and the dynamic toolbar covers up the textfield. (At that point I can scroll the page slightly to hide the dynamic toolbar and reveal the textfield.)

This reproduces essentially-the-same regardless of whether the textfield is at the top or bottom. It reproduces regardless of whether the navbar is enabled, too. However, there's no issue if I scroll to hide the dynamic toolbar before I tap the textfield, or if I disable the dynamic toolbar entirely.

Chrome gives EXPECTED RESULTS (regardless of whether their dynamic toolbar is visible vs. scrolled-away when I tap the textfield). Though interestingly it seems like their dynamic toolbar unconditionally reappears when the keyboard comes up, and it refuses to scroll away at that point.

Comment 22

[Hiroyuki Ikezoe (:hiro)]

Thank you Daniel for finding out the remaining issue. I filed bug 1951016 for it.

Comment 23

[Hiroyuki Ikezoe (:hiro)]

Though I've posted patch in bug 1951016, it doesn't fix the remaining issue on Fenix. We also need bug 1900622.

Comment 24

[Botond Ballo [:botond]]

Requesting webcompat re-triage for this bug.

Based on these symptoms:

(In reply to Daniel Holbert [:dholbert] from comment #21)

Under these circumstances: when you tap the "Type a message" textfield and the keyboard appears, it's got the dynamic toolbar still-present just above the keyboard, and the dynamic toolbar covers up the textfield. (At that point I can scroll the page slightly to hide the dynamic toolbar and reveal the textfield.)

since the user is able to bring the text field into view by scrolling the page slightly, per the triage guidelines I believe the right impact assessment for this bug would be impact:annoyance rather than impact:workflow-broken.

Likewise, I don't think this meets the severity criteria for S2.

Comment 25

[Sky Schubert [:skyschub]]

Agreed with Botond.

Comment 26

[Calin Tanase]

This is still an issue on the latest Nightly (v148).

Comment 27

[Daniel Holbert [:dholbert]]

(In reply to Calin Tanase from comment #26)

This is still an issue on the latest Nightly (v148).

I'm guessing it might be because:

• This was fixed by bug 1951016 -- hiding the dynamic toolbar when keyboard is up -- per comment 22.
• And we recently reverted that behavior, sort of, so that the dynamic toolbar does show up again when the keyboard is up. (In bug 2001536 maybe, or a related bug.)
• Specifically, in current Nightly 2025-12-21, the dynamic toolbar appears unconditionally whenever I tap a textfield to bring up the keyboard (here on this bugzilla page at least).

Comment 28

[Hiroyuki Ikezoe (:hiro)]

Something has been totally broken since bug 1988730.

When the software keyboard is shown, Fenix forcibly set the dynamic toolbar max height to zero, the code was introduced in bug 1988730. It disables the dynamic toolbar, which means it breaks one of the advantages of interactive-widget=resize-visual mode since it causes full reflow.

We need to stop doing it. CCing :petru.

I will take a deep look again later. So keep NI to me.

Comment 29

[Hiroyuki Ikezoe (:hiro)]

Calin, just to clarify, what you are still seeing is slightly different from is what we can see in the recording in comment 0, right? I mean, the current issue is some part of the input box is covered up by the toolbar?

Comment 30

[Petru-Mugurel Lingurar [:petru]]

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

Something has been totally broken since bug 1988730.

When the software keyboard is shown, Fenix forcibly set the dynamic toolbar max height to zero, the code was introduced in bug 1988730. It disables the dynamic toolbar, which means it breaks one of the advantages of interactive-widget=resize-visual mode since it causes full reflow.

We need to stop doing it. CCing :petru.

I will take a deep look again later. So keep NI to me.

I'm open to suggestions on how otherwise to keep the toolbar fixed when the user is entering text in a website.
Technically when this happens we currently configure the toolbar as it was fixed in place - not dynamic.
Current behaviour (visual) matches what Chrome does and was requested by product.

Maybe we'd need a callback into APZ to request a special kind of reflow which would help in these specific scenarios?
For context: there is a tentative plan to also show a minimal toolbar at the top while entering text and then also show a minimal toolbar instead of the full one whenever the page is being scrolled. We'd definitely need the layout to easily adapt to the changes in toolbar heights.

Comment 31

[Hiroyuki Ikezoe (:hiro)]

(In reply to Petru-Mugurel Lingurar [:petru] from comment #30)

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

Something has been totally broken since bug 1988730.

When the software keyboard is shown, Fenix forcibly set the dynamic toolbar max height to zero, the code was introduced in bug 1988730. It disables the dynamic toolbar, which means it breaks one of the advantages of interactive-widget=resize-visual mode since it causes full reflow.

We need to stop doing it. CCing :petru.

I will take a deep look again later. So keep NI to me.

I'm open to suggestions on how otherwise to keep the toolbar fixed when the user is entering text in a website.
Technically when this happens we currently configure the toolbar as it was fixed in place - not dynamic.
Current behaviour (visual) matches what Chrome does and was requested by product.

Yeah at first glance it looks like it matches Chrome's behavior but in fact it doesn't match Chrome's behavior as a web browser unfortunately.

Maybe we'd need a callback into APZ to request a special kind of reflow which would help in these specific scenarios?

I don't think it solve this issue at all. With interactive-widget=resizes-visual or interactive-widget=overlays-content any reflow should NOT be triggered by the browser.

I'd suggest backing bug 1988730 out for now.

Comment 32

[Petru-Mugurel Lingurar [:petru]]

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

Yeah at first glance it looks like it matches Chrome's behavior but in fact it doesn't match Chrome's behavior as a web browser unfortunately.

Maybe we'd need a callback into APZ to request a special kind of reflow which would help in these specific scenarios?

I don't think it solve this issue at all. With interactive-widget=resizes-visual or interactive-widget=overlays-content any reflow should be triggered by the browser.

I'd suggest backing bug 1988730 out for now.

Created bug 2007493 to just disable this by default for now but still have the feature around for more tests.
I'm curious about the follow-up, seems like something that APZ needs to support - but IMO this would be triggered by integrators like Fenix - it is the one owning and deciding the behavior of the toolbars, banners etc wrapping the browser which then needs to adapt the shown web content to the toolbars configuration sent by integrators.
This flow reminded me of bug 2006842 - it is possible that Fenix will show or hide different toolbars & banners at the top/bottom the screen. These would be dynamic or not and we need APZ to support them & their behaviour changing at anytime. Maybe we can link more bugs and work to this incipient meta?

Comment 33

[Calin Tanase]

The chat box is partially visible when triggering the keyboard in some cases and on the other, same as before.

Comment 34

[Hiroyuki Ikezoe (:hiro)]

Great, thanks. Then things are simple. When the keyboard is shown, Fenix calls setDynamicToolbarMaxHeight(0) but it does just change the layout viewport, it does NOT change the visual viewport so that Gecko doesn't know the minimal toolbar at all, thus it still covers up the chat box.

Comment 35

[Petru-Mugurel Lingurar [:petru]]

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

Great, thanks. Then things are simple. When the keyboard is shown, Fenix calls setDynamicToolbarMaxHeight(0) but it does just change the layout viewport, it does NOT change the visual viewport so that Gecko doesn't know the minimal toolbar at all, thus it still covers up the chat box.

To offer a bit more context, Fenix would call setDynamicToolbarMaxHeight(0) & setVerticalClipping(0) within the minimal toolbar implementation but that feature is for now disabled.

This Pinterest bug seems to be reported for v. 134 where Fenix does not call setDynamicToolbarMaxHeight for keyboard visibility events - and without the minimal toolbar it doesn't call this method in the latest Nightly either.

Comment 36

[Calin Tanase]

The input box is now partially visible on latest Nightly on every attempt and on Chrome the keyboard overlaps the input box in 7 out 10 tries (on the other 3 it gets shown normally).

Comment 37

[Botond Ballo [:botond]]

My understanding is that at this point, this bug only affects configurations where the "minimal toolbar" is enabled, which is a Secret setting that's disabled by default (and moreover currently not even visible in the Secret settings menu).

Based on recent discussions, re-enabling the minimal toolbar will require some additional design work (and is likely blocked on platform work such as bug 1921339) so it's not going to happen in the immediate future.

I think it's fine to keep this bug open as a blocker for the eventual re-enablement of the minimal toolbar, but it shouldn't be a user-impact-score: 300 bug, since the currently shipping configuration is not affected.

I'm not sure what is the best way to reflect this in the bug flags -- maybe this shouldn't be a site-report any more? For now I am resetting the Webcompat Priority flag.

Comment 38

[Daniel Holbert [:dholbert]]

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

My understanding is that at this point, this bug only affects configurations where the "minimal toolbar" is enabled

I can still reproduce some trouble in default-configured Nightly on Android, though it's not as bad as it was originally. Nowadays, the problem is that the "Type a message" textfield is partially covered by the keyboard, when the keyboard appears (and then you can scroll to fully reveal it). I'll attach a screenshot of Firefox vs. Chrome. (This is with current Nightly on my Pixel 10 Pro XL as well as my Pixel 6a.)

I'm not sure what is the best way to reflect this in the bug flags -- maybe this shouldn't be a site-report any more? For now I am resetting the Webcompat Priority flag.

In cases where conditions have changed such that the score feels inaccurate, the best way to recompute the score is to update the data that feeds into it using the Site Issue Triage tool https://addons.mozilla.org/en-US/firefox/addon/site-issue-triage/ (click the lightbulb icon at top right of url bar when viewing this bug, and then select "Triage" from the dropdown menu, and then adjust fields as-needed).

Given that I'm seeing this still reproduce but to a lesser extent, I'm going to suggest we downgrade "Notable annoyance" to "Minor annoyance", which moves the score from 300 to 50, which feels reasonable I think.

Comment 39

[Daniel Holbert [:dholbert]]

Attachment: screenshot of Nightly 149 on Android, with partially-covered textfield when keyboard appears

Comment 40

[Daniel Holbert [:dholbert]]

Attachment: screenshot of Chrome 145 on Android, with fully-visible textfield when keyboard appears

Comment 41

[Daniel Holbert [:dholbert]]

(In reply to Calin Tanase from comment #36)

The input box is now partially visible on latest Nightly on every attempt and on Chrome the keyboard overlaps the input box in 7 out 10 tries (on the other 3 it gets shown normally).

(FWIW Nightly 149/Chrome145 behave consistently like my attached screenshots, on my Pixel 10 Pro XL and Pixel 6a. I'm not seeing the Chrome variability that you describe.)

Comment 42

[Hiroyuki Ikezoe (:hiro)]

As of now that's an expected behavior unfortunately. When we try to scroll the focused input element into view, the target content of the scrollIntoView is the caret, not the outer input box.

So for example, given that the input box is a multi-line editor box, scrolling the entire multi-line box into view might not result a good UX. We may be able to do better heuristic there. It would be nice to open a new bug for improvement.

Comment 43

[Botond Ballo [:botond]]

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

As of now that's an expected behavior unfortunately. When we try to scroll the focused input element into view, the target content of the scrollIntoView is the caret, not the outer input box.

So for example, given that the input box is a multi-line editor box, scrolling the entire multi-line box into view might not result a good UX. We may be able to do better heuristic there. It would be nice to open a new bug for improvement.

Filed bug 2018087.