105166 - premature page break printing nytimes.com

Status: VERIFIED FIXED

(Core :: Layout, defect, P2)

Description

[karnaze (gone)]

This is a spinoff of bug 66804 which was fixed but got reopened because new urls 
kept getting added to it.

Comment 1

[sujay]

this also happens for http://www.businessweek.com

Comment 2

[sujay]

*** Bug 105206 has been marked as a duplicate of this bug. ***

Comment 3

[sujay]

just wanted to explain here what the symptoms for this bug are since
we're starting to get DUPS.

banner or top graphic is being printed on first page.
and rest of the content is being printed on sucessive pages..

Comment 4

[karnaze (gone)]

Attachment: reduced test case with image not splitting

Comment 5

[karnaze (gone)]

In the attachment, the cell block containing the tall spacer gif (I increased 
the height to 1500 from 900 in the url) does not split. As a result, the table 
does not split, so the body puts the table on the next page to give it more 
space to truncate. One approach would be to split images when they exceed a 
certain percentage of the page height. 

Kevin, I'm not sure who should get this.

Comment 6

[karnaze (gone)]

taking this back to investigate splitting images.

Comment 7

[karnaze (gone)]

Attachment: patch to split images

Comment 8

[Alexandru Savulov]

Comment on attachment 54323 [details] [diff] [review]
patch to split images

r= alexsavulov

Comment 9

[Marc Attinasi]

Comment on attachment 54323 [details] [diff] [review]
patch to split images

sr=attinasi - way cool Chris!

Comment 10

[karnaze (gone)]

Comment on attachment 54323 [details] [diff] [review]
patch to split images

r=alexsavulov

Comment 11

[karnaze (gone)]

Attachment: revised patch

Comment 12

[kinmoz]

Comment on attachment 55971 [details] [diff] [review]
revised patch

sr=[e-mail]

Comment 13

[Alexandru Savulov]

Comment on attachment 55971 [details] [diff] [review]
revised patch

r= alexsavulov

Comment 14

[karnaze (gone)]

Attachment: revised patch in -u format

Comment 15

[karnaze (gone)]

Attachment: revised patch including minor nsTableCellFrame change, this is the last I promise

Comment 16

[karnaze (gone)]

The patch is in.

Comment 17

[sujay]

verified in 11/2 trunk build on windows

verified the following URLs print banner AND content together in continuous
sequence on the same page:

http://www.businessweek.com
http://www.nytimes.com
http://www.washingtonpost.com

Comment 18

[karnaze (gone)]

Attachment: I guess I lied, this needs to be applied after the 5th attachment

Comment 19

[karnaze (gone)]

Comment on attachment 56840 [details] [diff] [review]
I guess I lied, this needs to be applied after the 5th attachment

sr=attinasi

Comment 20

[Dawn Endico]

removing item for this fixed bug from mozilla 0.9.6 release notes.

Comment 21

[steve bowden]

Is fix applied to trunk yet - I'm confused by the latest comments.
I'm running 2001110803 and problem still exists. Apologies if fix not applied 
yet.

Comment 22

[sujay]

this should be fixed in trunk builds....if not let me know...
I will recheck

Comment 23

[sujay]

just verified on 11/9 trunk build.

I printed http://www.businessweek.com and it printed out the banner
and content together. Thus this is fixed still.

here are other test URLs:

http://www.nytimes.com
http://www.washingtonpost.com

Comment 24

[steve bowden]

Downloaded trunk 2001111303 and tested with html scipt as posted on bug 80966 
(my original post for this bug). The script is taken from a cisco web page. It 
does not print the table correctly. It should print the table following the text 
as does ie and netscape 4.76 and not start a new page. Also on the new page it 
prints the table header then leaves a gap which is done on the following page as 
well. This bug is not fixed in this build.

Comment 25

[sujay]

Steve,

are you sure what you are describing is the same as this bug ?

Why don't we take this discussion over to bug 80966 

Comment 26

[steve bowden]

sujay, have you run the test as described? Bug 80966 was eventually transferred 
to this bug! It does prematurely print a page break! Isn't that what this bug is 
about? 
It's to do with determining how to print a table that is longer than the page 
length. And it's not fixed.

Comment 27

[karnaze (gone)]

nytimes.com fluctuates between being fixed and not. Right now with an 11/13 
debug build it prints ok for me. A few days ago that was not the case. This 
could be happening because the content on that pages changes often. But until 
someone can attach a case that fails, please leave this bug closed.