1473501 - Improve the way Gecko selects images based on srcset values (don't just round up, when rounding up is a huge jump)

Status: NEW

(Core :: Layout: Images, Video, and HTML Frames, enhancement, P3)

Description

[Karl Dubost💡 :karlcow]

I'm opening this issue because in a couple of cases, we get an image which is slightly blurry in Firefox while Chrome seems to get a higher resolution image.


1. Load URL on a phone.
2. Scroll down to image.
3. Compare to mobile Chrome.


We have at least two issues already with this behavior.

https://webcompat.com/issues/12774 
https://webcompat.com/issues/16836


There's a good discussion and analysis in 
https://webcompat.com/issues/12774#issuecomment-339094641

comparing what chrome and firefox do.

Comment 1

[Daniel Holbert [:dholbert]]

(In reply to Karl Dubost :karlcow (away from 2018-07-10 to 2018-07-25) from comment #0)
> I'm opening this issue because in a couple of cases, we get an image which
> is slightly blurry in Firefox while Chrome seems to get a higher resolution
> image.

That's an accurate description of the latter NatGeo webcompat issue that you linked.

However: I think the former webcompat issue ( https://webcompat.com/issues/12774 ) is substantially different -- there, Firefox was getting a *higher-res* (i.e. larger/wider) image as compared to Chrome.

(Also, a big part of the main issue there was that the website was lying about the image resolutions. I don't think that's the case with this NatGeo scenario.)

So there may be different problems... Unfortunately I can't investigate the NatGeo issue because I'm getting just-fine image resolutions on my (Google Pixel 2) mobile device -- no blurriness/low-qualitiness visible.

Comment 2

[Daniel Holbert [:dholbert]]

Correction: per updates on the NatGeo webcompat issue, it's hitting the same sort of issue as in https://webcompat.com/issues/12774 after all.

The general webcompat issue here is that *Firefox* is picking a higher-resolution image than Chrome is. We round up when deciding between sources, whereas Chrome rounds to the nearest (possibly picking an image whose "###w" specifier is lower than the screen resolution). Or something like that.

And this is particularly problematic (for us) when rounding up is a large jump whereas rounding down would be a small jump.

Comment 3

[Firefox Bug Husbandry Bot]

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Comment 4

[Firefox Bug Husbandry Bot]

See bug 1547409. Migrating whiteboard priority tags to program flags.

Comment 5

[Ksenia Berezina [:ksenia]]

1. https://webcompat.com/issues/12774 - humanize.me/yo/loremcobsum.html returns 404
2. https://webcompat.com/issues/16836 - nationalgeographic.com issue is not reproducible on my phone, but still could be an issue on other phones
3. https://webcompat.com/issues/19239 - changed site design, the issue is not reproducible anymore
4. https://webcompat.com/issues/74453 - changed site design, the issue is not reproducible anymore

Comment 6

[Ksenia Berezina [:ksenia]]

Hi Raul, was wondering if you could check if the issue with nationalgeographic.com in https://github.com/webcompat/web-bugs/issues/16836 is still reproducible on the phones you have, please?

The phones that Sergiu tested on are listed in the comment https://github.com/webcompat/web-bugs/issues/16836#issuecomment-402957221

Comment 7

[Daniel Holbert [:dholbert]]

I wonder if Chrome's behavior has changed here? In some brief local testing, they seem to be rounding up in the way that I described in comment 2.

I'll attach a testcase to demonstrate & perhaps investigate if they changed.

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: resource for testcases: 50x50 image

Comment 9

[Daniel Holbert [:dholbert]]

Attachment: resource for testcases: 200x200 image

Comment 10

[Daniel Holbert [:dholbert]]

Attachment: resource for testcases: 600x600 image

Comment 11

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Comment 12

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (loading all images first to try to work around Chrome bug)

Hmm, testcase 1 seems to reveal an interesting Chrome bug (in old and current version) where any relayout causes them to use the 600x600 image throughout the testcase. That makes this behavior difficult to investigate, because image loads can cause a relayout, in testcase 1 at least.

Here's a modified version that tries to work around that (not yet sure if it does) by forcing all of the images to load first, before displaying them with srcset/sizes.

Comment 13

[Daniel Holbert [:dholbert]]

Hmm, testcase 2 shows the same issue. Chrome 121 - 126 at least seem to match Firefox on this at first-load (rounding up to the next size image per comment 7), but as soon as I trigger an incremental layout (e.g. by zooming or resizing the viewport), they snap every image to be the 600x600 one. Chrome versions before that (120 and below) seem to choose the 600x600 image up-front.

So: my testcases are capturing an interesting Chrome quirk, but we don't yet have a testcase that demonstrates the originally-described behavior-difference that this bug was filed for. I'll try to come up with one later on today. (context-switching to something else right now, though.)

Comment 14

[Daniel Holbert [:dholbert]]

Attachment: testcase 3 (using dummyimage.com)

For what it's worth, here's the test snippet that I quoted in this github comment (using disposable custom-sized images hosted on dummyimage.com which fortunately still works):
https://github.com/webcompat/web-bugs/issues/12774#issuecomment-339094641

Comment 15

[Daniel Holbert [:dholbert]]

testcase 3 does render differently for me in Chrome vs. Firefox on my Pixel 8 phone, for what it's worth (in a way that sounds like what we were describing on this bug originally, where Chrome was rounding down and we were rounding up to decide which image to use).

Loading testcase 3, on my Pixel 8 in portrait orientation:

• Firefox Nightly shows the 2208x1472 image
• Chrome shows the 1200x800 image

Comment 16

[Daniel Holbert [:dholbert]]

(In reply to Ksenia Berezina [:ksenia] from comment #6)

Hi Raul, was wondering if you could check if the issue with nationalgeographic.com in https://github.com/webcompat/web-bugs/issues/16836 is still reproducible on the phones you have, please?

I took a quick look at the nationalgeographic.com site from that issue, and it looks like the site design has changed -- they just have a single image URL now, without srcset.

archive.org does have historical versions of the page captured from the same time period as our screenshots from the webcompat issue, but those versions don't load any images, unfortunately (either the images weren't archived, or the site depends on some script that doesn't load properly in the archived version).

So I think testcase 3 is our best still-testable version of this issue that I'm aware of (for me at least).

Comment 17

[Daniel Holbert [:dholbert]]

Just retested; comment 15 is still accurate in Nightly 133.0a1 2024-10-27 vs. Chrome 130, on my Pixel 8 running Android 15. (We pick a larger image from the srcset attribute as compared to Chrome, as noted in comment 15.)