Bug 88817 – WebKit incorrectly paginates positioned items.

• Status: RESOLVED
• Resolution: INVALID
• Component: Printing

[Vitaly Buka]

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.

[Vitaly Buka]

I tried IE, Firefox, Opera. Behaivour is inconsistent.
I believe that the best solution is do like Firefox. It avoids pagination of positioned items.

[Vitaly Buka]

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.

[Vitaly Buka]

Created attachment 147026 [details]
Draft

[WebKit Review Bot]

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

[WebKit Review Bot]

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

[Vitaly Buka]

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.

[Vitaly Buka]

One more argument against applying transformation before pagination is regions+animation. It's bad if moving object jumps to next region on touching edge.

[Vitaly Buka]

Any comments on this?

[Eric Seidel (no email)]

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.

[Eric Seidel (no email)]

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. :(

[Vitaly Buka]

(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.

[Vitaly Buka]

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.

[Vitaly Buka]

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.

[Dave Hyatt]

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.

[Vitaly Buka]

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".