1575539 - Search icon on howstuffworks.com is broken on Firefox with layout.css.devPixelsPerPx=1.25, because of a too large icon

Status: RESOLVED DUPLICATE of bug 1583707

(Core :: Layout: Text and Fonts, defect, P3)

Description

[Lyubomir [:mystiquewolf]]

Attachment: Search icon on Chrome

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:70.0) Gecko/20100101 Firefox/70.0

Steps to reproduce:

1. Open https://home.howstuffworks.com/induction-cooktops2.htm on both Firefox and Chrome
2. Look at the search icon

Actual results:

The search icon is broken on Firefox, unlike on Chrome.

Expected results:

Search icon should be correct on both browsers.

Comment 1

[Lyubomir [:mystiquewolf]]

Attachment: Search icon on Firefox

Comment 2

[Lyubomir [:mystiquewolf]]

Attachment: Troubleshooting info

Comment 3

[Hani Yacoub, Desktop QA]

Couldn't reproduce this issue on Ubuntu 18.04 x64 on Firefox Nightly 70.0a1, Firefox 69.0b16 and on Firefox 68.0.2.

Could you please try to reproduce this issue using a fresh profile? You have the steps here: https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles?redirectlocale=en-US&redirectslug=Managing-profiles#w_starting-the-profile-manager

Thanks.

Comment 4

[Lyubomir [:mystiquewolf]]

Problem seems to be related to having layout.css.devPixelsPerPx set to 1.25. Issue is that anything larger than 1.00 breaks the page. I have GNOME Tweaks Fonts -> scaling set to 1.25. Chrome seems to use the value from GNOME Tweaks to set it's scaling, and the site works fine with 1.25 scaling set for Tweaks. With 1.25 however set to layout.css.devPixelsPerPx the site is broken.

Firefox needs to have the ability to show the text as large as in Firefox, while still not breaking the site.

Comment 5

[Hani Yacoub, Desktop QA]

Assigning "Core: Layout" component for this bug.

Comment 6

[Emilio Cobos Álvarez (:emilio)]

Well, tweaking layout.css.devPixelsPerPx not only tweaks the font-size, but also has a lot of other side effects. So this is kind of expected.

I guess the issue then is that Firefox doesn't respect the GNOME font scaling, which is a fairly different issue... Is that right? Or did I misunderstand?

Comment 7

[Lyubomir [:mystiquewolf]]

You are somehow right. But what i am trying to say is that while Chrome respects the GNOME font scaling, setting Firefox to render the page at 1.25 scaling from it's about:config results in a broken page, while implicitly setting Chrome to render at 1.25 by changing the GNOME tweaks doesn't break the page icon.

So there is no way in Firefox to display text big enough so it can be read easily without breaking the page, while in Chrome there seems to be a way.

Comment 8

[Emilio Cobos Álvarez (:emilio)]

Sure, sure, I understand, thanks for confirming.

The fix is then applying gnome system scaling to font sizes, not fixing the page with a different devPixelsPerPx.

That may or may not need layout work, depending on how we make it work, I guess...

Comment 9

[Emilio Cobos Álvarez (:emilio)]

Hmm, circling back a bit on this and looking closer at that particular page... That site seems to be relying on the glass icon to be exactly 18 CSS pixels wide, so any kind of text-only zooming (like what you get with View > Zoom > Text Only) obviously breaks the site.

But in Chrome it's not breaking. That's because they're doing the equivalent to layout.css.devPixelsPerPx with the GNOME font scaling...

The site with layout.css.devPixelsPerPx=2.5 (I have a hidpi screen, so that's the equivalent to 1.25 on a non-hidpi one) looks fine. With 1.25 it does not however.

That's weird, because the site has font-size: 18px, so I'd expect given it's an icon font for the icon to be 18px wide exactly. For some reason it only seems to happen at that particular devPixelsPerPx, and not others... Any zoom makes it go away... Maybe we're mis-accounting for devPixelsPerPx somewhere?

I'll make this about figuring out that particular issue, if you want to file a Core::Widget:Gtk bug to account for the default pixel scaling, please do so.

Comment 10

[Emilio Cobos Álvarez (:emilio)]

Attachment: font for test-case

Comment 11

[Emilio Cobos Álvarez (:emilio)]

Attachment: Test-case

The icon at devPixelsPerPx=1.25 shows a size of 18.4 rather than the expected (at least by that page's author) 18px.

Comment 12

[Emilio Cobos Álvarez (:emilio)]

Jonathan, is the test-case above in comment 11 something you're interested in looking into? I'm not sure why we'd come up with different CSS pixel sizes for that font given the same inputs to font-matching, but I don't know the font-matching algorithm as well and maybe there's some antialising going on at some device pixel sizes or something?

If you don't have the time to look into this please redirect the ni? back and I'm happy to poke at this on rr to see where the final size of 18.4 comes from.

Comment 13

[Jonathan Kew [:jfkthame]]

I believe what's happening here is that on Linux, we don't currently support sub-pixel glyph widths (in device pixels, that is). So a glyph that would nominally be 18px wide (in CSS px), at devPixelsPerPx of 1.25, works out at 22.5 device pixels wide, which rounds to 23 dev px. Converted back to CSS px, that's 18.4px.

So the issue is the rounding of glyph widths to device pixels, combined with the fractional devPixelsPerPx ratio.

:lsalzman has been working on getting rid of some of our dependency on cairo for Linux font stuff, which IIRC is where the device-pixel rounding comes from, so we may be able to move to fractional-pixel glyph positioning at some point... pinging Lee for any additional info here.

Comment 14

[Emilio Cobos Álvarez (:emilio)]

Ah, of course, d'oh, should've realized the round(18 * 1.25) / 1.25 :)

Thanks!

Comment 15

[Lee Salzman [:lsalzman]]

(In reply to Jonathan Kew (:jfkthame) from comment #13)

I believe what's happening here is that on Linux, we don't currently support sub-pixel glyph widths (in device pixels, that is). So a glyph that would nominally be 18px wide (in CSS px), at devPixelsPerPx of 1.25, works out at 22.5 device pixels wide, which rounds to 23 dev px. Converted back to CSS px, that's 18.4px.

So the issue is the rounding of glyph widths to device pixels, combined with the fractional devPixelsPerPx ratio.

:lsalzman has been working on getting rid of some of our dependency on cairo for Linux font stuff, which IIRC is where the device-pixel rounding comes from, so we may be able to move to fractional-pixel glyph positioning at some point... pinging Lee for any additional info here.

Bug 1583707 has landed now, so if that was going to fix it, it should have by now.

Comment 16

[Emilio Cobos Álvarez (:emilio)]

Yeah, the reduced test-case is fixed. The website changed and it is still broken on Linux, but it's broken on Chrome too, because they expect the search button to not have borders.