Closed Bug 430153 Opened 17 years ago Closed 1 year ago

zooming woes, zooming rounding errors break page/design, javascript math

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: axel.bugzilla, Unassigned)

References

(
URL
)

Details

(Keywords: testcase)

Attachments

(1 file)

Testcase
556 bytes, text/html
Details
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3) Gecko/2008020513 Firefox/3.0b3 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3) Gecko/2008020513 Firefox/3.0b3 At this page, at first the 2 tables are equally long. Slowly zooming in step by step, first the left table is longer than the right, suddendly a gap appears, then it disappear, then the right table is longer than the left. etc. This is not only terrible for design, where one could argue, oh its just a pixel up or down. For example I have an javascript (GWT) application, that does some arithmetic, to lineup various components. Its terrible when you have a website where 4px + 5px can equal to a corresponding 10px or 8px or 11px, differing on the page zoom level of the browser. Reproducible: Always Steps to Reproduce: 1. view that page 2. slowly zoom with your ctrl+scrollwheel 3. be terrified. Actual Results: Lineup breaks, page math breaks. Expected Results: What is equally long at zoomlevel 0, shall be equally long in any zoom level, indiffirent of how the components build this length up.
just a random minimal page to demonstrate the zooming random woes. <html> <body> <table> <tr><td> <table style="border: solid 1px;"> <tr> <td style="height: 20px;"> </td> </tr> </table> </td> <td> <table style="border: solid 1px;"> <tr> <td style="height: 7px;"> </td> </tr> </table> <table style="border: solid 1px;"> <tr> <td style="height: 7px;"> </td> </tr> </table> </td></tr> </body> </html>
Below my new favorite, load page, go to make zoom level, and hit "test"... Now 7+7==15 :-(((( ------------- <html> <head> <script language='javascript'> function test() { var e1 = document.getElementById('a1'); var e2 = document.getElementById('a2'); var e3 = document.getElementById('a3'); document.getElementById('out').innerHTML = e1.offsetWidth + " + " + e2.offsetWidth + " == " + e3.offsetWidth + " ?"; } </script> </head> <body> <input type="button" onClick="test();" value="test"> <br/> <span style="font-family: monospace"> <span id="a3"><span id="a1">W</span><span id="a2">W</span><br/> </span> <p/> <span id="out">.</span> </body> </html> --- I hope this stuff gets fixed before FF is released. (On a side note I'm not too found of this page zooming at all. I always took care my pages zoomed well in classic text-zoom, and IMHO the new pagezooming capabilities try to turn what was ****-designed webpages before to a virtue now...
s/go to make zoom level/go to max zoom level/g
I just tested this in Opera and IE7 in both x+x is always 2x, while in Opera a letter of with x px always stays x px, in IE7 this changes but the total span is at least always the addition of the two smaller spans. Not that IE7 page zooming is otherwise fundamentally broken :-) (And Opera I could not deeply check on my application, because I can't use it, because of the broken onKeyPress handling...) I also noticed there is a <br/> to much in the example of Comment #2, just make it: <span style="font-family: monospace"><span id="a3"><span id="a1">W</span><span id="a2">W</span></span> Problem stays the same. Kind Regards, Axel
Status: UNCONFIRMED → NEW
Component: General → Layout
Ever confirmed: true
OS: Linux → All
Product: Firefox → Core
QA Contact: general → layout
Hardware: PC → All
Attached file Testcase —
The testcase for the spanning rounding error.
We support subpixel layout so a span can have width 10.5 pixels, for example. But offsetWidth always returns an integer, the rounded value of the true width of a span. So for example you could have two spans of width 10.3 each. They each have an offsetWidth of 10, but together they have an offsetWidth of 21. Use getBoundingClientRect to compute your widths and the problems should mostly go away, because it can return fractions.
Robert, as far I recognized the pixels I get returned for e.g. offsetWidth do not repesent the actual pixels on screen at a certain zooming level but (roughly) the amount of pixels it would have been, if at zooming level 100%. So if I set a div to be 100px wide, and ask its offsetWith while at zooming level 150% it still returns (roughly) 100px, never 150px. But now its like 102.34px ... So it is IMHO a logical falacy. Since, shouldn't the JS ideally not be able to "see" (say bothered with) current zooming view? Even not having to start to worry about subpixels?
(In reply to comment #7) > Robert, as far I recognized the pixels I get returned for e.g. offsetWidth do > not repesent the actual pixels on screen at a certain zooming level but > (roughly) the amount of pixels it would have been, if at zooming level 100%. That is correct. > So if I set a div to be 100px wide, and ask its offsetWith while at zooming > level 150% it still returns (roughly) 100px, never 150px. But now its like > 102.34px ... If you actually use width:100px on the div, and no borders, then offsetWidth should always return 100. Do you have a testcase that shows otherwise? > So it is IMHO a logical falacy. Since, shouldn't the JS ideally not be able to > "see" (say bothered with) current zooming view? Even not having to start to > worry about subpixels? No, because the layout depends on the zoom factor. See http://weblogs.mozillazine.org/roc/archives/2007/10/a_tale_of_two_z.html for more information.
Hmmm, There is one thing I do not understand, when I first read your comments first I thought, oh! maybe the spans had never an integer width at 100% zoom to start with. But something subpixel and only got rounded to integer. But thats not the case 100 double-u do have exactly the 100 times the width of a single double-u. So when the browser tells me the offset witdth is say 7px this should stay 7px no matter which zooming level you are with. And when you don't have subpixels at 100% zooming views, isn't it a bug subpixels get introduced as soon you get to any zooming levels?
You do have subpixel sizes at 100% zoom on Linux and Mac. We don't have them on Windows just because Windows GDI rounds all text metrics to integer device pixels. But when you zoom in to say 200%, then if Windows tells us a character is 19 device pixels wide, that's going to be 9.5 CSS px.
I am testing on Linux, and since 100 double-u is exactly 100 times the width of a single double-u I'm conclude that in this particular case no subpixels are involved at default zooming stage. Take marijns example. Okay he does get the exact fractionals value. http://martijn.martijn.googlepages.com/b.html But why is 7px at 100% zooming stage, suddendly reported as 7.199px when zooming on step in? Shouldn't it always stay 7px?
But Opera and IE don't have changing offsetWidths on different zoom levels. I guess they don't use glyph hinting?
They probably do use glyph hinting because the text looks bad otherwise especially at small sizes. But I don't really know what they do. You might be able to figure it out with some clever experiments.
Severity: normal → S3

Closing as INCOMPLETE; the URL that this bug was filed about doesn't load anymore, and the attached testcase looks fine when zoomed, so it's not clear if there's still a bug here. (and 16 years have passed, and the reporter's bugzilla account is no longer active, so unfortunately we can't check back with them at this point.)

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: