22937 - [DOGFOOD] Tables take up too much space when printed

Status: VERIFIED FIXED

(Core :: Layout, defect, P3)

Description

[Akkana Peck]

Print the given url, which includes a set of tables which are one row each.  The
page displays correctly in the browser window, but when printed, each table
takes up a full page so the output isn't useful.

Marking this dogfood because I had to go back to 4.61 to print a page which had
this structure.

Comment 1

[shrirang khanzode]

Changing Platform to ALL. Saw this problem on today's Windows and Mac commercial
builds also.(2000010308)

Comment 2

[dcone (gone)]

This is a problem with pagenation, etc.  I think this is you Troy, but it could
be Chris Karnaze or Buster. I will copy all three and initially give it to Troy
since he probably understands this better than anyone and will know the right
person this should go to.

Comment 3

[leger]

dcone, PDT needs feedback on what exactly the issue/problem is here.  We think
this is PDT-, but are there any highly visible top pages that are affected by
this?

Comment 4

[chriss]

I encountered this bug with yesterday's build when trying to print this page:
http://news.cnet.com/news/0-1003-200-1513284.html?tag=st.ne.1002.

I ended up with about 20 pages, with each page looking like a table element.
This makes printing unusable on many pages.

Per discussion with the PDT, changing status to PDT+

Comment 5

[dcone (gone)]

This is that yahoo problem we were looking at yesterday.. this is a simpler
case...

Comment 6

[dcone (gone)]

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

Comment 7

[karnaze (gone)]

Troy, can you take a look at this. I may have caused it but I'm not sure. DonC
has promised to add printing regression tests (which will take some work) to
avoid problems like this in the future.

Comment 8

[dcone (gone)]

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

Comment 9

[troy]

Print preview doesn't work in viewer.exe anymore, and when I try to bring up the
print preview windiw we crash (see stack trace below). Re-assigning to Don to
see if he can fix this, and then I'll be able to take a look at why printing is
also horked.

nsPresContext::SetShell(nsPresContext * const 0x0217a078, nsIPresShell *
0x02189400) line 251 + 46 bytes
PresShell::Init(PresShell * const 0x02189400, nsIDocument * 0x020d8b90,
nsIPresContext * 0x0217a078, nsIViewManager * 0x020f7f70, nsIStyleSet *
0x02175210) line 726
nsMarkupDocument::CreateShell(nsMarkupDocument * const 0x020d8b90,
nsIPresContext * 0x0217a078, nsIViewManager * 0x020f7f70, nsIStyleSet *
0x02175210, nsIPresShell * * 0x02177f0c) line 74 + 28 bytes
nsHTMLDocument::CreateShell(nsHTMLDocument * const 0x020d8b90, nsIPresContext *
0x0217a078, nsIViewManager * 0x020f7f70, nsIStyleSet * 0x02175210, nsIPresShell
* * 0x02177f0c) line 378 + 25 bytes
DocumentViewerImpl::Init(DocumentViewerImpl * const 0x02177ed8, void *
0x00010622, nsIDeviceContext * 0x02177e10, nsIPref * 0x00000000, const nsRect &
{...}, nsScrollPreference nsScrollPreference_kAuto) line 428 + 90 bytes
nsWebShell::Embed(nsWebShell * const 0x0218a730, nsIContentViewer * 0x02177ed8,
const char * 0x0042827c, nsISupports * 0x00000000) line 853 + 98 bytes
nsBrowserWindow::Init(nsIAppShell * 0x00f36ff8, nsIPref * 0x00e9b910, const
nsRect & {...}, unsigned int 16, int 1, nsIDocumentViewer * 0x00fb4bb8,
nsIPresContext * 0x0217a078) line 1333
nsBrowserWindow::ShowPrintPreview(int 40051) line 2400
nsBrowserWindow::DispatchMenuItem(int 40051) line 618
nsNativeBrowserWindow::DispatchMenuItem(int 40051) line 125
HandleBrowserEvent(nsGUIEvent * 0x0012fdb0) line 345 + 21 bytes
nsWindow::DispatchEvent(nsWindow * const 0x00f1970c, nsGUIEvent * 0x0012fdb0,
nsEventStatus & nsEventStatus_eIgnore) line 502 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012fdb0) line 523
nsWindow::ProcessMessage(unsigned int 273, unsigned int 40051, long 0, long *
0x0012fe5c) line 2508 + 21 bytes
nsWindow::WindowProc(HWND__ * 0x000205e4, unsigned int 273, unsigned int 40051,
long 0) line 689 + 27 bytes
USER32! 77e135f8()
USER32! 77e13769()
USER32! 77e17b9a()
main(int 2, char * * 0x00a95088) line 137 + 11 bytes
mainCRTStartup() line 338 + 17 bytes

Comment 10

[troy]

Oh, and of course I can't try print preview inside of mozilla.exe because theer
I assert in the RDF code while trying to bring up the browser window...

Comment 11

[dcone (gone)]

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

Comment 12

[dcone (gone)]

The problem with the printpreview has been fixed.  A bogus DocShell was being
created with the WebSHellIID instead of the DocShellIID.  Back to you Troy..

Comment 13

[troy]

Fixed the table problem

Comment 14

[shrirang khanzode]

Verified the fix on Win(2000011408) and MAC(2000011408) commercial builds.
Waiting for workable Linux build to verify on.

Comment 15

[shrirang khanzode]

Verified using Linux commercial build (2000011808M13). MArking as VERIFIED.