Open Bug 477157 Opened 11 years ago Updated Last month
Borders scale differently than other sizes (e
.g . margins, content-sizes, backgrounds), under full-page-zoom or Hi DPI
STR: 1. Load attached testcase 2. Zoom in and out, examining output at various zoomlevels EXPECTED RESULTS: No red should be visible, at any zoom level. ACTUAL RESULTS: Many zoomlevels show red slivers, between the divs and on their edges. Basically, this indicates that we aren't scaling background-rects and border-rects in the same way, during full-page-zoom. (We're rounding in a different way, or something like that.) I'm pretty sure this is the same issue I described in bug 472769 comment 43 and bug 472769 comment 44.
I can reproduce this, zooming in 1x, with both Firefox 3.0.5 and with the latest mozilla-central nightly. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:188.8.131.52) Gecko/2008121711 Ubuntu/9.04 (jaunty) Firefox/3.0.5 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090205 Minefield/3.2a1pre
Here's a reference case. It just differs from the testcase in that it uses a *background* instead of a *border* to draw the blue rectangles. (It's the same size in both cases, so in theory, they should behave the same) I get no red at any zoomlevel using this reference case. (I tested it with both Firefox 3.0.5 and with my mozilla-central nightly.)
Here's a simple reftest for this bug.
Here's what we get from this reftest right now. In the failure reftest-snapshot, it looks like the rectangle is at least 1px shorter & skinnier than its reference case, and the bottom & right edges look grayish, when they should be solid black.
Note also that in the attached reftest patch, the testcases 477157-1a.html and 477157-1b.html look identical to each other when viewed at zoomlevel 1.0 (i.e. if you view the files directly).
This is probably intentional. Border widths are always adjusted to be exact multiples of device pixels, in the style system. This ensures that border lines with the same specified width are always rendered with the same width in device pixels after the border line rectangles are snapped to device pixels. Backgrounds are just snapped to device pixels. I think the border behaviour explains why at some zoom levels borders aren't covering the set of pixels you expect.
See also 499821, which only uses 'background' (no borders) and has "seams" similar to those in this bug at various zoom levels, breaking wiki.mozilla.org
I run into this problem with Ext toolkit, but I am sure that they are not the only one affected. Up until now on all browsers the "correct" way to get numeric value from "computed style" was to use "parseInt( ... )" (to get rid of "px" suffix). This is how it is coded in endless number of existing applications. As you can imagine with border width been reported as fractional, results are far from expected. Considering the fact that no other browsers (have not tried Chrome) behave differently, was it really good idea to "scale" width like this? Other thing which makes this questionable is the fact that it "breaks" relations between "offsetWidth/offsetHeight", "clientWidth/clientHeight" and "border width/height", padding. Out of these 4 sizes, border width is the only "scaled" value. So as soon as you are using non-default zoom level, formula: offset == client + border + padding is not true. It is my understanding that this formula is part of a standard.
Sorry, second paragraph should read: Considering the fact that no other browsers (have not tried Chrome) behave like this, ...
Regression-range good http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2007/10/2007-10-25-04-trunk/firefox-3.0a9pre.en-US.win32.zip bad http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2007/10/2007-10-26-05-trunk/firefox-3.0a9pre.en-US.win32.zip http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-10-24-01&maxdate=2007-10-26-01&cvsroot=%2Fcvsroot It's more obvious when zooming with Ctrl+Mousewheel instead of Ctrl+NumPad+/- due to the smaller intervals. Note: Before 2007-10-26, the testcase isn't zoomable at all.
Dholbert, is this a valid bug? Comment 7 suggest that it isn't. We hit this regularly: https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&longdesc=bug%20477157&product=Firefox&product=Toolkit&longdesc_type=substring It would be good to know if we should accept this as a fact of life and keep working around it or whether we can expect this to be fixed some day.
[CC'ing some other folks who work in pixel-snapping-related code] (In reply to Dão Gottwald [::dao] from comment #13) > Dholbert, is this a valid bug? Comment 7 suggest that it isn't. I'm not sure. Per comment 7, our current behavior is the least-bad solution we had come up with at the time. Though: that comment & its reasoning predated ubiquitous HiDPI screens (which are like an always-on full-page-zoom, which therefore can make this much easier to trigger, particularly for intermediate HiDPI scale factors like 125%). > It would be good to know if we should accept this as a fact of life and keep > working around it or whether we can expect this to be fixed some day. For now, I think this is a fact of life -- but I'm not confident enough to close it as WONTFIX or INVALID. It's possible we'll eventually come up with a better solution that addresses the tradeoffs somehow, but I'm not seeing one at the moment.
Summary: Borders and backgrounds don't scale the same, in full-page-zoom → Borders and backgrounds don't scale the same, under full-page-zoom or HiDPI
Apparently the google.com and amazon.com front-pages have some minor visual :hover glitches that are caused by this bug on some HiDPI configurations (175% in particular) & also with high full-page-zoom-levels, as discussed over in bug 1399577. Also: bug 332275 will potentially open up another way for users to hit versions of this bug more frequently across the web. (by letting users set a value other than 100% as their default full-page-zoom value) We're not entirely on our own in our current behavior, FWIW -- Safari 11 matches us on this behavior (i.e. it shows red when you scale attachment 360825 [details] up or down with full-page-zoom, and it has the same issues described for us over in bug 1399577). But Edge and Chrome have taken a different approach and have none of these problems (though presumably their approach causes different problems). It'd be worth investigating what Edge/Chrome do here and seeing if it'd be worth changing, since this is a bit of a webcompat issue (at HiDPI, per bug 1399577), and it's an unintuitive/unexpected behavior for web developers to have to worry about coding for.
Summary: Borders and backgrounds don't scale the same, under full-page-zoom or HiDPI → Borders scale differently than other sizes (e.g. margins, content-sizes, backgrounds), under full-page-zoom or HiDPI
"But Edge and Chrome have taken a different approach and have none of these problems (though presumably their approach causes different problems)" Daniel I think I may have found one of these such issue: both Edge and Chrome have this issue when system scaling is 175%, but Firefox doesn't https://bugs.chromium.org/p/chromium/issues/detail?id=793060 If changing Firefox to behave like Chrome and Edge would result in Firefox also having that issue on twitter.com, maybe Firefox made the right choice.
Webcompat Priority: --- → ?
You need to log in before you can comment on or make changes to this bug.