1869335 - The background color for the bottom action bar when drawing a scribble is dark at mail.google.com

Status: RESOLVED FIXED

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

Description

[Raul Bucata]

Attachment: Screenshot_1.png

Environment:
Operating system: Android 12/ Android 13
Firefox version: Firefox Nightly 122.0a1 (2015987303-🦎122.0a1-20231121183118🦎)

Preconditions:
Clean profile

Steps to reproduce:

1. Navigate to: https://mail.google.com/mail/mu/mp/175/#dl
2. Perform account login.
3. Tap on the "Compose" button (pen icon).
4. From the "Subject" input field, tap on the attachment icon.
5. Tap on the "Draw scribble" button and observe the bottom action bar.

Expected Behavior:
The background color for the action bar is light

Actual Behavior:
The background color for the action bar is dark

Notes:

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

Comment 1

[Calin Tanase]

Verified this issue and it's still reproducible on Firefox versions 123 and 125.

Environment:
Operating system: OnePlus 6 A6000 (Android 11)
Browsers: Firefox Nightly 125.0a1-20240225092952 / Firefox Release 123.0-20240212203859 / Chrome 122.0.6261.64

Note: Not reproducible on Chrome

Comment 3

[Daniel Holbert [:dholbert]]

I can reproduce in Responsive Design Mode on desktop.

The bug reproduces specifically if I use a Firefox-for-Android UA string. If I instead use a Chrome-for-Android UA string, then I get the expected rendering.

In particular, in Firefox, this action-bar footer element (with id="dvtbb" for me) is dark because it's got class "PRCEm" which grants it this border-image styling, with a dark data-URI image:

.PRCEm {
  border-image:url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAUAAAAABCAIAAAAggeCAAAAAb0lEQVQoz42RQRLAIAgDl+e10/9/J73YjiMY8SSELIhx3Q8ARAT7s6h/WLqMmqWpJIzXoIYzyXb+tbr53n7H/XKK3HHhJ8LMsjIIOVVGUs1rEApvyujkqgaQQSrFxpzhu+7fRQs1FRhvS5X8Twl4AZzxRuH3oNopAAAAAElFTkSuQmCC) 2 0 0 0 fill stretch;
  border-top:1px solid #4b4c4e;
  border-width:1px 0 0;
  color:white
}

That border-image covers up the actual background, which is a lighter color.

If I remove that attribute from this element [EDIT]
If I untick the border-image declaration there, then we get the same rendering as Chrome (and as Firefox-pretending-to-be-Chrome).

So: this is a site bug where they're mistakenly adding (only in Firefox) a border-image that breaks the rendering, and we should reach out to Google folks to get it addressed.

Comment 4

[Daniel Holbert [:dholbert]]

Here's a sample UA string that triggers the issue:

Mozilla/5.0 (Android 14; Mobile; rv:132.0) Gecko/132.0 Firefox/132.0

Here's a sample UA string that does not trigger the issue (from our "Galaxy S20 Android 11" option in Responsive Design Mode):

Mozilla/5.0 (Linux; Android 11; SAMSUNG SM-G973U) AppleWebKit/537.36 (KHTML, like Gecko) SamsungBrowser/14.2 Chrome/87.0.4280.141 Mobile Safari/537.36

Comment 5

[Daniel Holbert [:dholbert]]

Actually I guess the element has the same class "PRCEm" in Firefox-pretending-to-be-Chrome, too. The key difference is that the style rule for that class (in an inline <style> element) is different -- it's missing the above-quoted troublesome border-image declaration. So presumably Google should just fix whatever's inserting that border-image into that style rule when viewed in a browser with a Firefox UA string.

[edited comment 3 to clarify]

Comment 6

[Daniel Holbert [:dholbert]]

I emailed our discussion list with Google folks to give them a heads-up about this.

[--> switching from "needs-diagnosis" to "site-wait"; denschub, please feel free to further adjust keywords if that's not the right edit or if further tweaks are needed]

Comment 7

[Daniel Holbert [:dholbert]]

Good news: Google folks have a fix for this which should be deployed within a few weeks, I think!

Comment 8

[Daniel Holbert [:dholbert]]

The STR give me EXPECTED RESULTS in Nightly now, so I think Google's fix has been deployed.

Raul, would you mind retesting to verify?

Comment 9

[Calin Tanase]

Works as expected for me as well. Tested with the latest Nightly (133.0a1-20241007093651).