1447447 - Jumping/disappearing content at fractional zoom levels, due to border-sizes rounding differently from other sizes (snapping to device pixels)

Status: RESOLVED DUPLICATE of bug 477157

(Core :: Layout, defect, P3)

Description

[M. Turnhout]

Attachment: ZoomTest.html

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

Steps to reproduce:

1. Open attached "ZoomTest.html"
2. Zoom to 110%
3. Hover over a div on the right


Actual results:

When hovering over a div it replaces "margin:10px" with "margin:6px;border:4px...". This works fine on 100% and 150% zoom. But between it and hovering over a div on the right it breaks the alignment. The next div ends up directly underneath it. And the other div's end up on the rows after that one.

The hover part is trivial. It doesn't seem to handle the margin/border correctly when zooming between 100% and 150%.

Chromium:
https://bugs.chromium.org/p/chromium/issues/detail?id=822665

IE and Edge do not have this issue.


Expected results:

Just like 100% and 150% to not break the float alignment.

Comment 1

[Jet Villegas (inactive)]

[Triage 2018/03/23 - P3]

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (can you see the lime area at nondefault zoom levels?)

Here's another testcase, reduced from https://github.com/webcompat/web-bugs/issues/89019 , which is hitting the same root issue.

The problem here (in both testcases) is that the site is assuming margin: Npx and border: Npx will occupy precisely the same amount of space. But in fact they aren't precisely the same size, because we snap borders to exact display-pixel boundaries to keep them precise.

At bahn.de, the actual content has margin-top: -2px combined with border: 2px, and the site's logic precisely depends on those being exactly the same size. But in fact, we round the border down very slightly in order to snap it to exact display pixels, which means the negative margin-top causes the content to overlap with the preceding content.

And due to how floats work, this turns out to cause the element to size itself to be 0 width, which bahn.de is not expecting. (Chrome agrees with us on this part, if I manually specify a slightly-more-negative margin-top to intentionally make the margin-top extend beyond the border).

So the key thing here is just our difference in rounding behavior for borders.

Comment 3

[Daniel Holbert [:dholbert]]

This is basically a duplicate of bug 477157, which emilio tried to fix last year, but it bounced due to causing other issues (bug 1645008), because there are some fundamental tradeoffs around pixel-snapping and borders (related to what happens at the seam between two adjacent fractionally-device-pixel-sized borders).

I do see that in bug 1645008 comment 32, emilio noted that WebKit changed to match our behavior at some point in the past; but they don't seem to be affected by this bug. (In the original testcase here, they don't have any issues at nondefault zoom levels; though I can trigger the broken layout if I manually change the margin a little bit).

emilio: do you know how close WebKit's behavior actually is to ours, and do you understand how they get away without hitting this bug?

Comment 4

[Emilio Cobos Álvarez (:emilio)]

I think WebKit implements zoom using the zoom property, not changing the DPI. So they're rounding effectively like using AppUnitsPerDevPixelAtUnitFullZoom() rather than this. That might be a reasonable change to do, wdyt?