1878024 - Account icon is squashed while logged in on g1.globo.com

Status: ASSIGNED

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

Description

[Calin Tanase]

Attachment: account icon FF vs Chrome.png

Environment:
Operating system: Windows 10
Firefox version: Nightly 124.0a1 (2024-01-31)

Preconditions: must be logged in

Steps to reproduce:

1. Go to https://g1.globo.com
2. Observe the account icon located at the top right corner of the page

Expected Behaviour:
Account icon is displayed correctly.

Actual Behaviour:
The account icon is squashed.

Notes:

1. Screenshot attached
2. Reproducible on Firefox Release as well
3. Reproducible for other subdomains as well (ge.globo.com / receitas.globo.com etc.)
4. Not reproducible on Chrome
5. Issue found during WebCompat team [Top100] websites testing

Comment 1

[Dennis Schubert [:denschub]]

This might be similar to bug 1878012, where we also have some weird proportion issue (in that case it's a SVG).

Comment 2

[Thomas Wisniewski [:twisniewski]]

We don't have a login to test with, so we're stuck.

Calin, could you try to use my Testcase Reducer addon to get us a test-case to work with? (Feel free to reach out to me if you'd like guidance on how to use it).

Comment 3

[Calin Tanase]

As discussed via slack, the affected area won't be visible when using the Testcase Reducer addon.

Note: Login can be performed with a google account.

Comment 4

[Jeff Muizelaar [:jrmuizel]]

Attachment: Standalone test case

Comment 5

[Jeff Muizelaar [:jrmuizel]]

Attachment: Somewhat reduced test case

Comment 6

[Jeff Muizelaar [:jrmuizel]]

Attachment: Reduced test case

Comment 7

[Jeff Muizelaar [:jrmuizel]]

Attachment: Reduced test case

More reduced this time.

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: testcase with canvas instead of img, showing that we're letting the img shrink

Thanks for the testcases. Here's one more with a <canvas> to make the markup a bit more compact (nice way to get a replaced element with an intrinsic width/height without needing a data URI).

It looks like Chrome is treating the replaced element's width: 100% as establishing its automatic minimum size, whereas we're giving it an automatic minimum size of 0. This testcase demonstrates that behavior-difference -- particularly the bottom part with the greedy sibling, where we let the replaced element be shrunk to have a content-box width of 0.

Comment 9

[Jeff Muizelaar [:jrmuizel]]

I tried your test case in Chrome, Safari, Servo and Ladybird and they all agree. Firefox is the odd one out.

Comment 10

[Daniel Holbert [:dholbert]]

Attachment: testcase with canvas but now with px-valued `width` (we match other browsers on this one)

If I adjust my testcase to use a px value for width instead of a percent (just filling in the value that the percent should ultimately resolve to), then we change to match Chrome.

Comment 11

[Daniel Holbert [:dholbert]]

I spun off bug 1927554 as a platform bug here.

Comment 12

[Ting-Yu Lin [:TYLin] (PST, UTC-7)]

Bug 1927554 is a dup of bug 1700474.

Comment 13

[Daniel Holbert [:dholbert]]

Hopefully we can get to an interoperable state on bug 1700474 before too long, but for the short term I'd suggest we sitepatch the issue here with the following:
===SUGGESTED SITEPATCH===

.base-container .button-login-icon img {
  flex-shrink: 0
}

===END SUGGESTED SITEPATCH===

This prevents this image from getting compressed in the way that it is now.

Additional background/notes:
The sitepatch is intended as an extension of the following CSS rule that the site has (at least, it's present in Jeff's "standalone reduced test case"):

.base-container .button-login-icon img {
  width: 100%;
  height: 100%;
  border-radius: inherit;
  margin-right: var(--spacing-50);
}

They're putting this image in a 32px by 32px flex container, and they give the image width: 100%; height: 100%; as quoted above to fill that container (i.e. the image tries to be 32x32) -- BUT they also give the image an 8px margin-right via that margin-right declaration (since they have --spacing-50: 8px defined elsewhere). So that 8px margin-right steals 8px of space from the container and forces the image to try to shrink, if it's shrinkable.

We don't have interop on whether or not an img is "compressible" in this situation (that's bug 1700474), but one trivial way to make it not compressible is to just give it flex-shrink:0.

Comment 14

[Daniel Holbert [:dholbert]]

Ah, hmm -- I just tested on the live site (logging in with a secondary Google account per comment 3) and I found that my suggested sitepatch doesn't quite work, since the element in question is inside of a custom element, and outside CSS rules (like e.g. a rule that I write in the Stylus addon-on in my case) doesn't match elements inside the shadow DOM of that custom element.

Tom, do you know if we have a way of shipping sitepatches that target the shadow-DOM internals of custom elements?

Comment 15

[Daniel Holbert [:dholbert]]

Ah, looks like we can do it with JS -- this works (note that there's only one <nova-barra-globocom> element in the page, so querySelector matches that one element and there aren't others to worry about). The timing of this JS might be a little fiddly though since that one element doesn't render right away. But if I wait for it to render and then execute this JS, things end up looking good.

let customElem = document.querySelector("nova-barra-globocom");
if (customElem) {
  let sheet = new CSSStyleSheet;
  let sheetText = ".base-container .button-login-icon img { flex-shrink: 0; }";
  sheet.replaceSync(sheetText);
  customElem.shadowRoot.adoptedStyleSheets.push(sheet);
};

Comment 16

[Thomas Wisniewski [:twisniewski]]

Attachment: Bug 1878024 - add a desktop-only JS intervention for g1.globo.com to fix user profile icons; r?denschub

Comment 17

[Jeff Muizelaar [:jrmuizel]]

This should really just be minor visual

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/197b47516708
add a desktop-only JS intervention for g1.globo.com to fix user profile icons; r=denschub,webcompat-reviewers

Comment 19

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/197b47516708