1399577 - when system scaling is 175%, hovering cursor over 'apps' on google.com causes them to twitch

Status: REOPENED

(Core :: Layout, defect, P3)

Description

[Will]

Attachment: googledotcomtwitch175ss.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20170824053622

Steps to reproduce:

Windows 10 v1703, system scaling is 175%, when I hover the cursor over the 'apps' on google.com, they twitch slightly. When I do the same in Edge and Chrome, they do not twitch. see attached screenshot

Comment 1

[Will]

also seeing this twitching-during-mouseover on amazon.com, same computer. The issue is that the system is 175% scaling, but Chrome and Edge don't have this issue

Comment 2

[Will]

Attachment: amazondotcomtwitchmouseover175percent.png

I put red rectangle over the buttons that 'twitch' when you hover your cursor over them. The issue is that I have Windows 10 set to 175% scaling

Comment 3

[Daniel Holbert [:dholbert]]

Thanks for the report!

I tested this at Google, and I can indeed reproduce the bug in Firefox 55.0.3.

Good news, though -- I can *not* reproduce in a recent Firefox Nightly 57 build (57.0a1 (2017-09-20) (64-bit)).  So, I think this was fixed in another bug somewhere -- hooray!  So, resolving as WORKSFORME (but feel free to reopen if you can still trigger this in a version 57 build.  (Firefox 57 will be released as "beta" in a few days, too, if you'd like to test & verify on your end on the quite-stable beta channel.  You can find the beta version at https://www.mozilla.org/firefox/channel/desktop/ )

Comment 4

[Will]

I can no longer reproduce this on google.com as of 57.01 but still can on amazon.com. There is a new issue on google.com though, as you hover the cursor over the icons there is a gray box that goes around the icons, but in firefox sections of the box are missing (attached screenshot, zoom into area red arrow is pointing to)

Comment 5

[Will]

Attachment: mouseover57.png

Comment 6

[Daniel Holbert [:dholbert]]

Thanks -- I can reproduce what you describe, and I can actually still reproduce the original bug if my Firefox window isn't fullscreen. Hence, reopening.

(E.g. if I visit google.com, do Ctrl+Shift+M to enter Responsive Design Mode, and then type in "800" as the viewport width -- and then when I click the icon for the apps (grid of boxes) at the top right of google and hover the individual apps, they shift a little bit to the side in their hover states)

This is all basically a version of bug 477157. In particular:

 1. Borders get special pixel-rounding behavior when we scale them up internally (different rounding behavior than for other properties), per bug 477157 comment 7.

 2. In the cases you're observing, the site is reacting to :hover by a few pixels to the border (e.g. 1px border in Google's case) and subtracting the same number of pixels from another size (e.g. 1px from the margin in Google's case).  And they're expecting this to exactly cancel out so that nothing moves and there's simply a border that appears.

 3. However, the border-addition & other-size-subtraction *don't* necessarily exactly cancel out, because as described in bug 477157 comment 7, we round borders to exact pixel-values aggressively & early on.  So 1px border scales to 1.75px (with your 175% scaling factor), which rounds to 2px of display pixels; whereas 1px of margin scales to 1.75px and stays at that value internally, since we're mostly happy to have fractional positions & sizes (but just not fractional border-sizes).

Unfortunately I don't know that there's a great solution for this. IIRC there might ways for web developers to reliably achieve the "border just appears" effect, regardless of zoomlevel, by using the "box-sizing: border-box" property.  For example, here's a jsfiddle that reproduces the bug by stealing from "margin" and transferring to "border" on hover:
  https://jsfiddle.net/93huveLb/

...vs here's one where I've adjusted it to use "box-sizing" so that the stealing is implicit:
  https://jsfiddle.net/ygxwroyu/

For now, I think our recommendation here is that sites should do something like the latter jsfiddle to avoid jumpiness.

(BTW, I think Chrome does not have the special border-scaling behavior described in bug 477157 comment 7, and that's how they avoid this problem.  At least, when I hover icons on the the Google Apps grid-dropdown at google.com, the top borders are all 2 display-pixels tall whereas the bottom borders are 1 display-pixel tall, despite the fact that they're all specified as being the same width.)

Comment 7

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #6)
>  2. In the cases you're observing, the site is reacting to :hover by a few
> pixels to the border (e.g. 1px border in Google's case) and subtracting the
> same number of pixels from another size

sorry, I left out a word there -- I meant to say "...by *adding* a few pixels to the border"

Also -- here's a reduced version of this issue that reproduces without any system scaling necessary:
 https://jsfiddle.net/41c8158g/

This testcase is just using :hover to swap between "margin: 0.5px" and "border: 0.5px" on a grid of inline-blocks. This triggers jumpiness in Firefox, because in Firefox (at 100% zoom-level), 0.5px of border is actually *larger* than 0.5px of margin (since we pixel-snap the border size).

Comment 8

[Will]

Daniel thank you for looking into this. If you have a moment, can you look at this very similar but I think different bug I just filed (system scaling is 200% this time, so I assumed the root cause is different) https://bugzilla.mozilla.org/show_bug.cgi?id=1422412

Comment 9

[Daniel Holbert [:dholbert]]

Sure! Yeah, that's the same root cause as this bug. I'll add a comment over there.

Comment 10

[Will]

Are you sure it's the same root cause though? The Windows system scaling is 200% and then if you increase or decrease Firefox's page zoom by 10% it makes them twitch...

Comment 12

[Will]

Do you think because of this issue, they should maybe delay the global page zoom option that's coming to Firefox soon? It's especially bad on amazon.com

Comment 13

[Daniel Holbert [:dholbert]]

(In reply to Will from comment #10)
> Are you sure it's the same root cause though?

Yes, see second half of bug 1422412 comment 1. System scale and full-page-zoom have the same overall effect, I believe - they impact the effective css-pixel-to-device-pixel scale factor, and whenever that factor is not an exact multiple, there's the potential for border pixel-snapping to cause trouble.

(In reply to Will from comment #12)
> Do you think because of this issue, they should maybe delay the global page
> zoom option that's coming to Firefox soon? It's especially bad on amazon.com

I'm not familiar with that -- where is that option being discussed/proposed?  Is that just like letting the user adjust the default full-page-zoom level?

Anyway, my default answer is "no, this shouldn't delay that feature", because:
 (a) That would mean an indefinite delay since we don't have a plan for a solution here at this point.
 (b) Win10 already ships effectively the same feature (a feature which has the same effective result for Firefox), so holding back this feature doesn't really protect our users from these bugs, as you've noticed.
 (c) When these glitches occur, they're annoying but not world-breaking.

This does all sound like we may want to reevaluate the tradeoffs we're making here, though, over in bug 477157.

Comment 14

[Will]

global zoom option https://bugzilla.mozilla.org/show_bug.cgi?id=332275

Comment 15

[Daniel Holbert [:dholbert]]

Thanks. I've added a note over there.

Also, FWIW, Safari 11.01 on Mac OS High Sierra matches our behavior here, if I zoom in 4 times (Cmd ++++), which I think takes them to something like 175% scale factor (~matching the test conditions that we've used here).

I tried viewing google.com, amazon.com, and the jsfiddles linked above, and Safari-with-Cmd++++ has all the same jitter noted above for Firefox.  So: we're not entirely on our own with our current behavior, and that's one vote for it not being entirely crazy, for what it's worth.  Having said that, we'd still like to avoid this problem, particularly as it gets easier to trigger.

Comment 16

[Will]

I'm very surprised Safari has this issue! Especially because Chrome doesn't have any of these issues on Windows 10. Have you tried Chrome on macOS to see if elements twitch when moused over?

Comment 17

[Daniel Holbert [:dholbert]]

Yeah, Chrome on MacOS doesn't show the twitch, with Cmd++++. (And I can zoom in bug 477157's testcase without any red showing up.)

So, Blink & Edge consistently behave one way; Gecko & WebKit consistently behave a different way.  So this must've been one thing that Google changed after they forked Blink off of WebKit.

Comment 18

[Will]

small update on this: when I hover the cursor over the apps grid on google.com, there is no longer any twitching. Google changed something on their end?

But I found a new place where I see the twitching during mouseover: a gmail menu

Comment 19

[Will]

Attachment: jitterduringmouseover.png

Comment 20

[Will]

please ignore the first part of comment 18, I forgot that I already said that

Comment 21

[Daniel Holbert [:dholbert]]

(In reply to Will from comment #18)
> But I found a new place where I see the twitching during mouseover: a gmail menu

Yeah, I can reproduce this (on Linux) if I use Ctrl ++++.

Here, Google is going between 2px padding (when un-hovered) to 1px of transparent-border and 1px of padding (when hovered), on the top and bottom sides.  (And this triggers this issue, because as noted in comment 6, we round fractional borders [e.g. from fractional zoom factors like 1.75x] differently from how we round other sizes.)  This happens via them adding a class called "J-N-JT" to the hovered element.

Gmail's behavior here doesn't make any sense to me, though. They choose a border that is the *same color* as the background, so there's no reason to do the border/padding swap. They could just as easily leave the sizing properties untouched and only change the background-color -- that would achieve the same hover effect without the jitteriness.  *shrug*

Comment 22

[Will]

Daniel would changing Firefox to behave like Chrome and Edge cause other issues?

Comment 23

[Daniel Holbert [:dholbert]]

Possibly.  See discussion in bug 477157 comment 15 (and your response to that comment, where you link to a Chrome bug for Twitter apparently depending on the Firefox/Safari pixel-snapping behavior).

Comment 24

[Daniel Holbert [:dholbert]]

(But basically: hard to say whether there would be issues.  There'd likely be a bit of fallout from sites like Twitter that happen to depend on our current behavior. This fallout may be limited, due to the fact that sites already have to account for the alternate Chrome/Edge behavior; however, we also could run into scenarios where a website serves different CSS to different browsers, and their Firefox-specific CSS might implicitly depend on our current behavior & break if we change how this snapping works.)