Bug 1869335 Comment 3 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Original comment by
on 
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;
}
```
That image covers up the actual background, which is a lighter color.

If I remove that attribute from this element, 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 a class that breaks the rendering, only for Firefox, and we should reach out to Google folks to get it addressed.
Revision 1 by
on 
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;
}
```
That image covers up the actual background, which is a lighter color.

If I remove that attribute from this element, 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 a class that breaks the rendering, only for Firefox, and we should reach out to Google folks to get it addressed.
Revision 2 by
on 
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:
```css
.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 image covers up the actual background, which is a lighter color.

If I remove that attribute from this element, 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 a class that breaks the rendering, only for Firefox, and we should reach out to Google folks to get it addressed.
Revision 3 by
on 
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:
```css
.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 a `border-image` that breaks the rendering, only for Firefox, and we should reach out to Google folks to get it addressed.
Revision 4 by
on 
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:
```css
.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.

Back to Bug 1869335 Comment 3