1885086 - Gmail (mail.google.com) places the action-bar at the top-right rather than at the bottom of the viewport, when you click a checkbox next to an email, if your browser has a Firefox UA string

Status: NEW

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

Description

[Calin Tanase]

Attachment: Chrome vs FF.png

Environment:
Operating system: OnePlus 6 A6000 (Android 11) / Google Pixel 5 (Android 14)
Firefox version: Nightly 125.0a1-20240312092552

Preconditions: must be logged in

Steps to reproduce:

1. Go to https://mail.google.com
2. Tap on a checkbox to select an email.
3. Observe the action bar that appears.

Expected Behaviour:
The action bar is located at the bottom of the screen.

Actual Behaviour:
The action bar is located at the top of the screen.

Notes:

1. Screenshot attached
2. Reproducible regardless of the ETP status
3. Reproducible on Firefox Release as well
4. Not reproducible on Chrome
5. Issue found during WebCompat team [Top100] websites testing

Comment 1

[Daniel Holbert [:dholbert]]

I can reproduce. This seems to be purely UA-sniffing-dependent; if I switch my UA string to be Chrome-on-Android (with e.g. the User Agent Switcher add-on), then I get the Expected Results.

This behavior-difference reproduces in Responsive Design mode, too. If I e.g. choose "Galaxy S20 Android 11" in Firefox RDM and visit gmail, then I get Expected Results (with the default Chromium UA string that we spoof for that RDM selection). If I then paste Mozilla/5.0 (Android 14; Mobile; rv:130.0) Gecko/130.0 Firefox/130.0 into the UA box and reload Gmail, then I get Actual Results.

So: this is a case of Google/Gmail giving browsers-that-claim-to-be-Firefox a different experience from browsers-that-claim-to-be-Chrome.

Comment 2

[Daniel Holbert [:dholbert]]

I also tested Chrome's own responsive design mode with a Firefox-for-Android UA string (using the exact Firefox UA-string from comment 1), and Chrome matches our "Actual results" in that configuration (showing the toolbar at the top-right of the viewport).

So there's no Firefox-specific behavior on our side here at all, other than the UA string itself.

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: screencast showing behavior in Firefox, with Chromium mobile UA string (left, fine) vs. Firefox mobile UA string (right, bad)