211813 - Printing and Print Preview hang (infinite loop, apparently)

Status: RESOLVED WORKSFORME

(Core :: Printing: Output, defect)

Description

[David Corbin]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030618
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030618

I have a .html page that I load from disk, and attempt to print.  However, after
the dialog with preparing in it comes up, I never get any further, and I have to
kill Mozilla.  I will attach the .html page.

Reproducible: Always

Steps to Reproduce:
1. Load the file (to be attached).
2. Change the page setup to: Landscape, scale to fit, print backgrounds(checked)
3. File-Print

Actual Results:  
The "preparing" dialog appears, and then hangs.

Expected Results:  
It should have printed.

Comment 1

[David Corbin]

Attachment: HTML file which causes hang.

Comment 2

[Jason Barnabe (np)]

Confirming on WinXP Moz 2003070107. Talkback TB21646481Y.

OS->All

Comment 3

[Jason Barnabe (np)]

Attachment: testcase

Text has to be longer than one page for the crash to happen.

Comment 4

[Jason Barnabe (np)]

It doesn't hang for me as the reporter says, it crashes.

Comment 5

[Matt Arnold]

Wow, that's rather impressive. With both testcases, Mozilla 1.4 in Linux crashes
to the desktop for me. FWIW, my Mozilla 1.4 is an XFT build I compiled myself.

Comment 6

[Matt Arnold]

Actually, when I use print preview Mozilla crashes to the desktop. When I try to
print it, Mozilla hangs like the original poster said. It does the same thing in
Mozilla 1.5b.

Comment 7

[Pratik]

fyi, I ran into this bug(?) too and fixed it on my XFT mozilla build by getting
rid of this pref from my prefs.js

user_pref("font.FreeType2.enable", true);

I don't think I need that pref anymore since I am running XFT builds. So people
on linux could try this out. I don't know about Windows folks.

Comment 8

[Alexander Zink :alex]

The same happens for me with one particular product page on www.ebay.de:
http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=3559646702&category=34313&rd=1

If I try to activate the print preview, a tiny window appears: 'preparing'.
Mozilla takes 100% CPU ressources and that's it. No more interaction possible.
All other pages seem to print (preview) fine.

Test platform: 
- Windows 2000 de; 
- Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.5) Gecko/20031007
(happens with both the original English installation as well as freshly
installed German installer distribution)
- Printer: Lexmark Optra R (both drivers: Postscript 2 and HP-Emulation mode)

Comment 9

[steve bowden]

Attachment: page from ferrysavers.com

The same thing happens with this page 
I'm using 1.7b and win me
is this the same bug

Comment 10

[Jason Barnabe (np)]

It doesn't do any good to see other pages that crash; we have a testcase already. 

How do you know those pages are showing the same bug? It could be a different
printing crasher bug. Unless you know it's the same underlying cause, you should
file a new bug.

Comment 11

[Christian Kuhröber]

(In reply to comment #10)
> It doesn't do any good to see other pages that crash; we have a testcase already. 
> 
> How do you know those pages are showing the same bug? It could be a different
> printing crasher bug. Unless you know it's the same underlying cause, you should
> file a new bug.

(In reply to comment #9)
> Created an attachment (id=145094)
> page from ferrysavers.com
> 
> The same thing happens with this page 
> I'm using 1.7b and win me
> is this the same bug

Hi,

I'm using Mozilla 1.7RC1 on OS/2 Warp CP1. This problem occurs to me since
version Mozilla 1.6 on any website I try to print. Neither the print nor the
print preview won't get further than the dialog showing "prepare". I can cancel
the print and use Mozilla quite normally. The same problem exists in Mozilla
Mail (no mails can be printed) and yesterday I tried it using Firefox 0.8 for
OS/2. Perhaps the following helps to find the cause: The print job appears in
the printer queue (when using the spooler), but the size of the job to be
printed remains 0 byte. I can cancel the print dialog. But after that the
current page can not be modified, i.e. you can not enter a new url or follow any
link. Do this results in a message, that the page cannot be changed while
printing. I can create new tabs and close the current tab. Afterwards mozilla is
 usable as you know it.

Kind regards
Christian

Comment 12

[Christian Kuhröber]

Hi there,

for my environment there was a strange behaviour: I had running USB drivers in
my system and Mozilla reacted in the way described in this bug. Disabling the
USB drivers leads to a well working Mozilla. Enabling the USB drivers again
leads to that strange behaviour (strange because there are several other things
that don't work correctly). Then I found a setting in my BIOS that changed
everyting: Assign IRQ to USB - Enabling this, leads to working USB devices and a
well working Mozilla. 
My question about that is: In what way do USB drivers have an impact on Mozilla
(Mozilla is the only application that appears to have problems)

For my environment this bug could be closed, but I don't know if this is the
solution of the bug.

Kind regards
Christiuan
> Hi,
> 
> I'm using Mozilla 1.7RC1 on OS/2 Warp CP1. This problem occurs to me since
> version Mozilla 1.6 on any website I try to print. Neither the print nor the
> print preview won't get further than the dialog showing "prepare". I can cancel
> the print and use Mozilla quite normally. The same problem exists in Mozilla
> Mail (no mails can be printed) and yesterday I tried it using Firefox 0.8 for
> OS/2. Perhaps the following helps to find the cause: The print job appears in
> the printer queue (when using the spooler), but the size of the job to be
> printed remains 0 byte. I can cancel the print dialog. But after that the
> current page can not be modified, i.e. you can not enter a new url or follow any
> link. Do this results in a message, that the page cannot be changed while
> printing. I can create new tabs and close the current tab. Afterwards mozilla is
>  usable as you know it.
> 
> Kind regards
> Christian

Comment 13

[Hideo Oshima]

Recent Firefox Trunk Linux build doesn't have this problem.
Worksforme?

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050404 Firefox/1.0+

Comment 14

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I cannot repro too.

-> WFM.

Comment 15

[Jimmy Yen]

Maybe this doesn't/no longer affect Linux builds, but apparently the testcase 
still crashes my Firefox 1.0.2 on Windows. Was the bug fixed in the trunk?

Comment 16

[Jason Barnabe (np)]

Works fine on the trunk now. I wouldn't expect it to be fixed on a branch.