1953721 - m.facebook.com - The keyboard overlaps the comment input field when triggered

Status: NEW

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

Description

[Raul Bucata]

Environment:
Operating system: Android 15
Firefox version: Firefox Mobile 136.0

Steps to reproduce:

1. Navigate to: https://m.facebook.com/ and perform account login
2. Select a post and tap on the "Comment" icon located below
3. Tap inside the comment input field and observe

Expected Behavior:
The comment field has a sticky position above the keyboard

Actual Behavior:
The keyboard overlaps the comment field

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/150295

Comment 1

[Raul Bucata]

Attachment: ff vs chrome

Comment 2

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

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

Comment 3

[Daniel Holbert [:dholbert]]

Sounds like maybe the same thing as bug 1943053 - maybe this will benefit (or did benefit) from the platform-bugs that that bug depends on -- bug 1900622 or bug 1943865 or bug 1951016. (Notably, the fix in bug 1951016 just landed, so it might be interesting to retest with latest Nightly in a day or so, or whenever current mozilla-central makes it to a Nightly.)

hiro, could you take a look and see if this is the same underlying issue/issues?

Comment 4

[Daniel Holbert [:dholbert]]

I can reproduce the bug in latest Nightly (2024-03-24). However, I'm not sure it's actually Firefox-specific.

I hit three different types of failures here:
(1) when I tap the textfield, the keyboard comes up and then immediately disappears.
(2) when I tap the textfield, the keyboard comes up but the content barely shifts upwards, so the textfield is way out of view.
(3) when I tap the textfield, the keyboard comes up and the content does shift upwards to bring the textfield mostly into view, but it's partly covered up by the dynamic toolbar (if you've got the toolbar at the bottom of the screen) or slightly offscreen (if you've got the dynamic toolbar at the top of the screen).

I think the original screencast here is showing category (2) of failure.

But I can reproduce categories (1) and (2) in Chrome on my phone (Pixel 9 Pro XL). It's a bit random so it doesn't happen every time, and it might happen more often in Firefox than in Chrome (it feels a bit like it from my testing just now), but it definitely does happen in both.

So far category (3) is only failure that seems entirely Firefox-specific to me here.

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: screencast showing the bug reproducing in Chrome

Here's a screencast showing the bug reproducing in Chrome.

My first two taps in the textfield trigger category (1) failures (and they cause the page to scroll a bit).
My third tap and in the textifled triggers expected results.
My fourth tap in the textfield (t=11s) triggers a category (2) failure.
My fifth tap triggers expected results.
My sixth tap (t=19s) triggers a category (2) failure.

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: screencast showing the bug reproducing in Firefox Nightly 138.0a1 2025-03-24

Here's a screencast showing the bug reproducing in Firefox Nightly.

My first tap in the textfield triggers a category (1) failure (and scrolls the page down by ~1 screen height).
My second tap in the textfield triggers a category (1) failure (but does not scroll).
My third and fourth taps in the textfield (t=7s) trigger category (2) failures.
Then I scroll back to the top and try again.
My fifth tap in the textfield (t=12s) triggers a category (3) failure.
My sixth tap in the textfield (t=16s) and all subsequent taps trigger a category (2) failure.

Notes/observations.

• In both Firefox and Chrome, we hit two category (1) failures right away (first two taps), which is an interesting pattern (and an interesting signal that things-are-pretty-broken-here, not through any fault of ours).
• We do hit category (2) failures much more reliably than Chrome does, based on my observations - though they happen for both of us. Not sure if that's due to some particular Firefox defect, or a race condition of some sort that we lose more often than Chrome does, or some particular quirk where certain scroll positions are unlucky and we happen to hit those more readily.... But probably we should pass this part along to folks at Facebook to investigate, since they affect multiple browsers.
• Category (3) failures are cases where we've got nearly expected results, and the taps that trigger that sort of failure do instead trigger expected-results if I disable the dynamic toolbar or scroll it out of view before tapping. (So there's a wrinkle to be ironed out there, but it's a case where things are mostly working properly.)

Comment 7

[Daniel Holbert [:dholbert]]

--> adding webcompat:needs-contact for categories (1) and (2).

Leaving needs-diagnosis to look into the category (3) failures where our dynamic toolbar is preventing us from quite getting expected-results here and partly covering up the textbox.

Comment 8

[Daniel Holbert [:dholbert]]

Hmm, I suspect category (3) is bug 1900622. Let's consider that part diagnosed as that bug.

Comment 9

[Daniel Holbert [:dholbert]]

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

--> adding webcompat:needs-contact for categories (1) and (2).

I just reached out to our point of contact for Facebook folks.

Comment 11

[Daniel Holbert [:dholbert]]

Didn't hear back to my outreach in comment 9; I sent another message today, inspired by bug 1986468 which I think is basically a duplicate of the same sorts of issues discussed here.