User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050420 Firefox/1.0+ Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050420 Firefox/1.0+ Per Bug 289480 Comment 6 , Bug 289480 Comment 12 , Bug 289480 Comment 18 , I enclose a testcase extracted from the Acid2 Action of the Web Standards project. Reproducible: Always Steps to Reproduce: 1.Like the original, it is necessary to go to the #top named anchor 2. 3. Expected Results: The expected render is available at http://www.webstandards.org/act/acid2/reference.html
Created attachment 181268 [details] Testcase for Acid2 Action I applaud the ingenuity of the individuals responsible for this test.
Created attachment 198439 [details] simplified testcase simplified testcase
*** Bug 315334 has been marked as a duplicate of this bug. ***
The real problem is that right floats are placed on the right side of their highest-level container (the window) instead of the right side of their lowest-level one (the 2nd line of the face, in case of Acid2). So if the screen (resolution=1024*768, browser window is considered fullscreen, margins are all set to zero, for simplicity) contains a 100*100 block that contains a small (5*5, for example) red block drawn as a right float, the red object is drawn outside the 100*100 block, at the right edge of the screen (upper left corner: x=1019, y=0; upper right one: x=1024, 1=0), whereas the expected result would be that the block's horizontal placement respects the block, so it's upper left corner goes to x=95, y=0, and it's upper right one is rendered at x=100, y=0.
(In reply to comment #5) > The real problem is that right floats are placed on the right side of their > highest-level container (the window) instead of the right side of their > lowest-level one That is the only really clear description that I have seen. 1. If a patch to obtain this behaviour were applied, would this solve this part of the Acid 2 Test? and, 2. Is it realistic for an entrey level preogrammer to identify the changes needed to produce such a patch?
I spent about twelve hours trying to figure out where in the code this is happening, the project is a bit too large to jump into. If I could widdle it down to one or two files to look in, I'd attempt it.
(In reply to comment #7) > I spent about twelve hours trying to figure out where in the code this is > happening, the project is a bit too large to jump into. If I could widdle it > down to one or two files to look in, I'd attempt it. This bug is fixed on dbaron's reflow branch (http://wiki.mozilla.org/Gecko:Reflow_Refactoring)
(In reply to comment #8) > This bug is fixed on dbaron's reflow branch > (http://wiki.mozilla.org/Gecko:Reflow_Refactoring) > In that case this Bug should be assigend to dbaron?
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20061208 Minefield/3.0a1 ID:2006120812 [cairo] Seems fixed by reflow branch landing
Fixed on trunk by reflow branch landing.
Adding in-testsuite? nomination per bz's request in m.d.t.l. Sorry for the bugspam.