Created attachment 146954 [details] Reproducer. 1. Open attached HTML with chrome or safari. 2. Open print preview. Expected: all "2" should be aliened in one row. Actual: Blue "2" is moved half line down. Original issue is http://code.google.com/p/chromium/issues/detail?id=112774 Problem happens when image is moved to page break by style="position: absolute;..", and than it's moved back using transform: matrix. Webkit assume that item is located on page break and move it to the next page by inserting some space above. However actual result is item moved inside the same page.
I tried IE, Firefox, Opera. Behaivour is inconsistent. I believe that the best solution is do like Firefox. It avoids pagination of positioned items.
Hi Dave, To fix this issue I need some input from you. My approach conflicts with your tests for https://bugs.webkit.org/show_bug.cgi?id=69896 Regressions: Unexpected image mismatch : (2) fast/regions/positioned-objects-block-static-spanning-regions-rtl.html = IMAGE fast/regions/positioned-objects-block-static-spanning-regions.html = IMAGE Small parts of "Some text." are little visible. It's easy to fix, but I am not sure if I can just tweak expected results. Maybe my assumption is completely wrong. http://www.w3.org/TR/CSS21/page.html is not clear about absolutely positioned elements. Can you take a look to attached HTML file https://bug-88817-attachments.webkit.org/attachment.cgi?id=146954? Please compare result with print preview. What do you expect for this case for green and blue columns? Another possible fix I see is to apply transformation matrix before pagination. However moving absolutely positioned items may break scene. For example imagine map tiles and small markers on top of them. Pagination may move tiles to the next page, leaving markers on white space. So if we just cut in the middle of tile without pagination it would produce better results. So I prefer just ignore pagination for positioned items. Thanks.
Created attachment 147026 [details] Draft
Comment on attachment 147026 [details] Draft Attachment 147026 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/12947433 New failing tests: fast/multicol/shadow-breaking.html fast/multicol/positioned-split.html
Created attachment 147044 [details] Archive of layout-test-results from ec2-cr-linux-01 The attached test failures were seen while running run-webkit-tests on the chromium-ews. Bot: ec2-cr-linux-01 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
It's even worse. It's also brake tests for https://bugs.webkit.org/show_bug.cgi?id=38402 and some more. So probably my approach is not an option. Still have no idea what is expected result here. Also applying transformation may rotate, skew block, so current pagination would require significant changes.
One more argument against applying transformation before pagination is regions+animation. It's bad if moving object jumps to next region on touching edge.
Any comments on this?
Comment on attachment 147026 [details] Draft Well, tehre are a few things wrong with this patch. To start: it's missing the ChangeLogs (which, for better or worse are a required part of patch submission for WebKit). http://www.webkit.org/coding/contributing.html Secondly, the indent looks wrong in your RenderBlock change. I'm surprised the style-bot didn't catch it. 3rd, it looks like the cr-linux bot doesn't like your patch (the bubble is red). you can click on the red bubble (and see the attached test failures) for more info.
I think if you read http://www.webkit.org/coding/contributing.html, you'll answer most of your questions here. :) Unfortunately contributing to any large open source project requires a bit of boot-up time. :(
(In reply to comment #10) > I think if you read http://www.webkit.org/coding/contributing.html, you'll answer most of your questions here. :) Unfortunately contributing to any large open source project requires a bit of boot-up time. :( Eric, please read log. It's not patch to commit, I need advice how to fix that.
Summury: 1. Pagination of positioned items with transformation does not work. 2. I thought about ignoring of positioned items during pagination. It does not work, because some region related code and tests rely on that. 3. Pagination with applying transformation may work, but require huge CL. Maybe use case is not worth that and I don't have time for this right now. 4. I am thinking about ignoring pagination for items with transformation. Anyway it does not work right now, but it will make result look consistent and reasonable. If you agree with #4, I well create patch for review.
Another reproducer. 1. Open in chrome or safary http://vrp.viamente.com/dd-oDZdU 2. Open Print preview 3. Switch to landscape paper orientation. Result is empty band on map.
Transforms can and should paginate according to their original positions. Remember, the whole point of transforms/relative positioning is that the offset does not affect layout. You do not paginate using the offset position. You paginate using the original position. This bug is invalid.
Thanks David. That's why I asked your opinion. Just to clarify please check this code: <div style="-webkit-transform: matrix(1, 0, 0, 1, 12, -801);position: absolute; top: 801px;"> Currently WebKit use "top: 801px;" for pagination, but don't use "-webkit-transform: matrix(1, 0, 0, 1, 12, -801)" and this is expected? Please change bug status, I only can set "Resolved".