1878012 - Icons (logo at bottom of page, menu-icons) are smaller on globo.com compared to Chrome, with HiDPI or full-page-zoom (devicePixelRatio != 1)

Status: NEW

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

Description

[Calin Tanase]

Attachment: logo FF vs Chrome.png

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

Steps to reproduce:

1. Go to https://www.globo.com
2. Scroll down until the bottom of the page is reached.
3. Check the size of the globo.com logo.

Expected Behaviour:
The logo size is normal.

Actual Behaviour:
The logo size is smaller compared to how it is displayed on Chrome.

Notes:

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

Comment 1

[Jeff Muizelaar [:jrmuizel]]

Attachment: Somewhat reduced test case

Comment 2

[Jeff Muizelaar [:jrmuizel]]

Safari, paints it the same as Chrome.

It looks like we're scaling the SVG image differently for some reason.

Robert, do you have some idea what might be going on here?

Comment 3

[Robert Longson [:longsonr]]

The SVG image has no width and no height or viewBox here (a viewBox on a <g> element is non-functional per the SVG specification). Is webkit doing something with that viewBox that they shouldn't? We really should get them not to if they are.

I imagine we should just display it at the desired height/width. I believe dholbert is looking at image sizing right now in bug 1916030 perhaps he could consider what's going on here too.

Comment 4

[Daniel Holbert [:dholbert]]

One initial observation -- the logo is actually exactly the same size in Firefox vs. Chrome if you have a window.devicePixelRatio of 1. (i.e. no HiDPI scaling, no full-page-zoom)

If I zoom in to increase my window.devicePixelRatio then I see the logo remaining the same size in Firefox, whereas it scales up in Chrome.

Comment 5

[Daniel Holbert [:dholbert]]

I might be wrong, but I think we render the SVG image in a virtual document without any devicePixelRatio-based pixel scaling, with just however many device pixels there actually are, treating them as if they were CSS Pixels.

This means that for us, a 40x40 rect in a dimensionless SVG image will always render at 40 device pixels wide and 40 device pixels tall (if the SVG lacks a viewBox, or width+height which provide an implicit viewBox when used as an image), regardless of how big of an image the SVG canvas is being rendered into, and regardless of the pixel-scaling in the outer "host" document. (So e.g. full-page-zoom won't make a difference, which matches what I'm observing.)

But I would guess Chrome and Safari are passing down the pixel-scaling factor, and they're using it inside of the inner SVG document, which would explain their behavior here. Probably we should be doing the same. (So the inner document should still get the same number of device pixels to fill as it currently gets, but we should interpret explicit lengths/sizes using with the appropriate CSS-pixels-per-dev-pixels ratio, to match the outer document, at least in the absence of viewBox-based scaling.)

Comment 6

[Daniel Holbert [:dholbert]]

I'll spin off a platform bug here with more details & a more targeted testcase in the morning. ni=me as a reminder.

Comment 7

[Jeff Muizelaar [:jrmuizel]]

Yeah, when I zoom the reduced test case the logo stays the same size in Firefox but zooms in Chrome and Safari

Comment 8

[Daniel Holbert [:dholbert]]

I filed bug 1918814 as the platform bug here.

Comment 10

[Daniel Holbert [:dholbert]]

As noted in bug 1846521 (which I just duped here), this affects the icons in the menu spawned by the top-left menu-icon, too.

Reduced testcase, using the first image from the menu:

data:text/html,<img src="https://s3.glbimg.com/v1/AUTH_fd78dc4be9404a2e92b908ade306e9e6/prod/header_menu_svgs/g1.svg">

(Firefox renders that^ image a different size in Firefox vs. other browsers if you have HiDPI or full-page-zoom applied.)