Bugzilla

Testcase #4 and #5 are meant to illustrate the vertical-writing-mode problem that I brought up in phabricator.  Ideally, we should really fix them here before landing...  But I'm not entirely opposed to addressing them in a followup.

Essentially: for a document with `writing-mode: vertical-lr` (or `vertical-rl`), its block axis (the axis we fragment/paginate in) is the horizontal axis.  So content that runs off the *side* of page 1 is what ends up on page 2, and content that runs off the *bottom* of page 1 should get lost. (This is the opposite of what happens in a document with a horizontal writing-mode.)

This axis-swapping works just fine with our regular fragmentation pipeline, but we get it backwards with this patch stack, due to its usage of vertical coordinates (y values and heights).

This should be fairly straightforward to address - it just requires that we deal with the overflow in terms of logical coordinates (LogicalRect, LogicalSize, etc; and the APIs that return those structs on nsIFrame) and the "B" (block-axis) components of those structs.

STR to see issues with testcase #4 and #5:
 1. Print the testcase, in a build with this bug's patch stack applied.
 2. In "More Settings", change "Scale" to "100% (not fit-page-width), to simplify things a bit.
 3. Look at the rendered preview.

EXPECTED RESULTS:
* In both testcases, the numbered list should be continued across all of the pages (just as it does for testcase 3, in a build with the patches here, aside from the bookkeeping noted in comment 24).
* In testcase #5, the "aaaaa..." should be truncated and should not show up on any other pages (just as it would if we added this to testcase 3)

ACTUAL RESULTS:
* In both testcases, the numbered list doesn't show up beyond the first page.
* In testcase #5, the "aaaa...." **is** painted on subsequent pages, even though it ran off the bottom (inline-axis-end edge) of the first page, and the subsequent pages are supposed to contain content that ran off the right side (the **block-axis-end edge**) of the first page.  In other words, page 2,3,etc. end up containing content that ran off of two different sides of page 1 (overflow from its bottom and right edge), which creates a weird frankenstein mashup of overflow. :)

Testcase #4 and #5 are meant to illustrate the vertical-writing-mode problem that I brought up in phabricator.  Ideally, we should really fix them here before landing...  But I'm not entirely opposed to addressing them in a followup.

Essentially: for a document with `writing-mode: vertical-lr` (or `vertical-rl`), its block axis (the axis we fragment/paginate in) is the horizontal axis.  So content that runs off the *side* of page 1 is what should end up on page 2, and content that runs off the *bottom* of page 1 should get lost. (This is the opposite of what happens in a document with a horizontal writing-mode.)

This axis-swapping works just fine with our regular fragmentation pipeline, but we get it backwards with this patch stack, due to its usage of vertical coordinates (y values and heights).

This should be fairly straightforward to address - it just requires that we deal with the overflow in terms of logical coordinates (LogicalRect, LogicalSize, etc; and the APIs that return those structs on nsIFrame) and the "B" (block-axis) components of those structs.

STR to see issues with testcase #4 and #5:
 1. Print the testcase, in a build with this bug's patch stack applied.
 2. In "More Settings", change "Scale" to "100% (not fit-page-width), to simplify things a bit.
 3. Look at the rendered preview.

EXPECTED RESULTS:
* In both testcases, the numbered list should be continued across all of the pages (just as it does for testcase 3, in a build with the patches here, aside from the bookkeeping noted in comment 24).
* In testcase #5, the "aaaaa..." should be truncated and should not show up on any other pages (just as it would if we added this to testcase 3)

ACTUAL RESULTS:
* In both testcases, the numbered list doesn't show up beyond the first page.
* In testcase #5, the "aaaa...." **is** painted on subsequent pages, even though it ran off the bottom (inline-axis-end edge) of the first page, and the subsequent pages are supposed to contain content that ran off the right side (the **block-axis-end edge**) of the first page.  In other words, page 2,3,etc. end up containing content that ran off of two different sides of page 1 (overflow from its bottom and right edge), which creates a weird frankenstein mashup of overflow. :)

Testcase #4 and #5 are meant to illustrate the vertical-writing-mode problem that I brought up in phabricator.  Ideally, we should really fix them here before landing...  But I'm not entirely opposed to addressing them in a followup.

Essentially: for a document with `writing-mode: vertical-lr` (or `vertical-rl`), its block axis (the axis we fragment/paginate in) is the horizontal axis.  So content that runs off the *side* of page 1 is what should end up on page 2, and content that runs off the *bottom* of page 1 should get lost. (This is the opposite of what happens in a document with a horizontal writing-mode.)

This axis-swapping works just fine with our regular fragmentation pipeline, but we get it backwards with this patch stack, due to its dependency on strictly vertical coordinates (y values and heights).

This should be fairly straightforward to address - it just requires that we look up overflow in terms of logical coordinates and APIs (LogicalRect, LogicalSize, etc; and the APIs that return those structs on nsIFrame) and the "B" (block-axis) components of those structs.

STR to see issues with testcase #4 and #5:
 1. Print the testcase, in a build with this bug's patch stack applied.
 2. In "More Settings", change "Scale" to "100% (not fit-page-width), to simplify things a bit.
 3. Look at the rendered preview.

EXPECTED RESULTS:
* In both testcases, the numbered list should be continued across all of the pages (just as it does for testcase 3, in a build with the patches here, aside from the bookkeeping noted in comment 24).
* In testcase #5, the "aaaaa..." should be truncated and should not show up on any other pages (just as it would if we added this to testcase 3)

ACTUAL RESULTS:
* In both testcases, the numbered list doesn't show up beyond the first page.
* In testcase #5, the "aaaa...." **is** painted on subsequent pages, even though it ran off the bottom (inline-axis-end edge) of the first page, and the subsequent pages are supposed to contain content that ran off the right side (the **block-axis-end edge**) of the first page.  In other words, page 2,3,etc. end up containing content that ran off of two different sides of page 1 (overflow from its bottom and right edge), which creates a weird frankenstein mashup of overflow. :)