350684 - Print preview of Wikipedia page hangs if scale factor other than 100%

Status: RESOLVED WORKSFORME

(Core :: Print Preview, defect)

Description

[Christian Franke]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko/20060729 SeaMonkey/1.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko/20060729 SeaMonkey/1.0.4

SM 1.0.4 hangs on print preview of specific Wikipedia page if landscape orientation is selected.

Reproducible: Always

Steps to Reproduce:
1. Open http://de.wikipedia.org/wiki/Elisabeth_von_%C3%96sterreich-Ungarn
2. File|Print Preview
3. Select Landscape
Actual Results:  
SeaMonkey hangs with 100% CPU.

Expected Results:  
SeaMonkey should not hang.

Portrait orientation is OK.

Also reproducible with SM 1.0b and SM 1.0.3.

The permanent link to the page:
http://de.wikipedia.org/w/index.php?title=Elisabeth_von_%C3%96sterreich-Ungarn&oldid=20695830

Comment 1

[Hermann Schwab]

wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1b2) Gecko/20060829 SeaMonkey/1.1b
Canon Bubblejet BJ 330

Comment 2

[Christian Franke]

Attachment: Diff between last working and first not working version of the page

This version was OK:
http://de.wikipedia.org/w/index.php?title=Elisabeth_von_%C3%96sterreich-Ungarn&oldid=17168166&printable=yes

This next version results in a hang:
http://de.wikipedia.org/w/index.php?title=Elisabeth_von_%C3%96sterreich-Ungarn&oldid=17183745&printable=yes

The only significant difference are image links in 4 nested div sections.
Bug could not be reproduced with locally stored version of the page.

Hope this helps.

Comment 3

[Hermann Schwab]

wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.0.6) Gecko/20060729 SeaMonkey/1.0.4
Printer driver: Canon Bubblejet BJ 330

tested using screen resolution 800x600 TrueColor(24bit)

http://de.wikipedia.org/wiki/Elisabeth_von_%C3%96sterreich-Ungarn
http://de.wikipedia.org/w/index.php?title=Elisabeth_von_%C3%96sterreich-Ungarn&oldid=17183745&printable=yes

If you are using this browser version, the "Version:" field of this bug should show "1.8Branch", not "Trunk"

Do you use extensions?
 

Comment 4

[Hermann Schwab]

confirming 
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1b2) Gecko/20060829 BonEcho/2.0b2
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1b2) Gecko/20060830 SeaMonkey/1.1b

Steps to Reproduce:

1. Open http://de.wikipedia.org/w/index.php?title=Elisabeth_von_%C3%96sterreich-Ungarn&oldid=20695830
2. File|Print Preview
3. select "Shrink to Fit"
3. Select Landscape
4. If it doesn't hang, change size to 175%, or 125%

I didn't see hanging at 100%. Firefox standard seems to be shrink-to-fit.

Comment 5

[Hermann Schwab]

I've also seen this bug on the "working" URL of comment 2:
http://de.wikipedia.org/w/index.php?title=Elisabeth_von_%C3%96sterreich-Ungarn&oldid=17168166&printable=yes

It doesn't depend on Landscape Mode, it depends on scale factor.

Steps to reproduce:
1. open permanent link from comment 0:
http://de.wikipedia.org/w/index.php?title=Elisabeth_von_%C3%96sterreich-Ungarn&oldid=20695830
2. open Print Preview, ensure Portrait mode, 100%, close Print Preview
3. open Print Preview, Portrait Mode, select 175% ==> Hang

Comment 6

[Hermann Schwab]

Using Firefox 2.0b2 I retested permanent link from comment 0:
http://de.wikipedia.org/w/index.php?title=Elisabeth_von_%C3%96sterreich-Ungarn&oldid=20695830

tested all standard scale factors 
in  Portrait mode: ok from 30% up to 150%, hanging: 175%, 200%
in Landscape mode: ok from 30% up to  90%, hanging: 100%, 125%

custom Scale factors in Landscape mode:
working: 94%, 96%, 97%
hanging: 98%

Conclusion:
1. in Portrait Mode Scale factors > 150% are hanging (exact limit not tested)
2. in Landscape Mode Scale factors > 97% are hanging

Comment 7

[Christian Franke]

Comment on attachment 236113 [details]
Diff between last working and first not working version of the page

(In reply to comment #5)
> I've also seen this bug on the "working" URL of comment 2:
> [...]

Agree. Attachment is misleading, set obsolete.

Comment 8

[Mats Palmgren (inactive)]

Possibly related to bug 323652.  A minimal testcase would help.

Comment 9

[Hermann Schwab]

(In reply to comment #8)
> Possibly related to bug 323652.  A minimal testcase would help.

I didn't succeed trying to get a working local copy, as CSS was missing.
view-source:http://de.wikipedia.org/wiki/Elisabeth_von_%C3%96sterreich-Ungarn
view-source:http://de.wikipedia.org/wiki/Bruttoinlandsprodukt

ok, CSS is here:
http://de.wikipedia.org//skins-1.5/monobook/main.css?9
http://de.wikipedia.org//skins-1.5/common/commonPrint.css

Looking at bug 323652, I assume it's the same bug.
testcase from bug 323652 seems to be simple enough:
view-source:https://bugzilla.mozilla.org/attachment.cgi?id=208737
https://bugzilla.mozilla.org/attachment.cgi?id=208737

Comment 10

[Martijn Wargers (dead)]

Attachment: testcase

I get this when minimising that wikipedia page.

Comment 11

[Hermann Schwab]

(In reply to comment #10)
> Created an attachment (id=237852) [edit]
> testcase
> 
> I get this when minimising that wikipedia page.

testcase WFM Portrait & Landscape Mode, tested up to 200%
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1b2) Gecko/20060911 BonEcho/2.0b2
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1b2) Gecko/20060910 SeaMonkey/1.1b

original URL still hanging tested on Firefox, memory is growing:
http://de.wikipedia.org/wiki/Elisabeth_von_%C3%96sterreich-Ungarn

Comment 15

[Carsten Book [:Tomcat]]

Confirmed also for trunk on Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9a6pre) Gecko/20070613 Minefield/3.0a6pre ID:2007061304 [cairo]

When i use the testcase from comment #10 i hang and the memory consume raises from around 150 MB to over 400 MB (then i killed the firefox process).

Comment 16

[Damon Sicore (:damons)]

Marking blocking 1.9 per Printing bug triage with Vlad, Stuart, and Dbaron.

Comment 17

[John Daggett (:jtd)]

Works for me in the latest trunk build:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007072205 Minefield/3.0a7pre

May have something to do with printer specified, before setting up a printer an error did occur.  Wasn't able to reproduce with new profile.

Also, prev page and next page controls are completely whacky, clicking on the next page button in the print preview window goes to the last page even though the page number shows 2 (of 7).  Repeatedly clicking next page increments the numbers until it hits the last page.

Comment 18

[Martijn Wargers (dead)]

The testcase was already worksforme, as also mentioned in comment 11.
The url became worksforme between 2007-07-03 and 2007-07-04:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-07-03+04&maxdate=2007-07-04+09&cvsroot=%2Fcvsroot

Comment 19

[Mats Palmgren (inactive)]

URL still hangs for me, 100% CPU, memory is NOT growing.
Page Setup: Portrait Mode, 150%

Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9a7pre) Gecko/2007072304 Minefield/3.0a7pre

Comment 20

[Carsten Book [:Tomcat]]

works for me in Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9a9pre) Gecko/2007092605 Minefield/3.0a9pre ID:2007092605

Mats, do you still see this problem ?

Comment 21

[Mats Palmgren (inactive)]

The URL on this bug and bug 368515 is WFM 2007092604 Linux.  It could be that
the pages has changed though.  I got a hang on the URL of duplicate bug 375230
with scale 150% in Portrait mode (100% CPU, memory growing),
and crashed with 110% Landscape: bp-1c4d29e6-6c94-11dc-a8dc-001a4bd46e84
and crashed with 90% Portrait: bp-6af683fd-6c95-11dc-864a-001a4bd43ef6

The new hang/crashes was not reproducible so it could be an entirely
different bug -- the hang here used to be 100% reproducible IIRC.

Comment 22

[David Mischel]

I confirm that Firefox 2.0.0.7 hangs on the URL in 375320, just as Mats reports: 100% CPU usage.

Comment 23

[Stuart Parmenter]

this WFM with both the url in this bug as well as the bug in

Comment 24

[David Mischel]

This is not resolved. I have 2.0.0.8. The recipe detailed in comment #5 of this bug causes the hang. I don't know how to change the status but it DOES NOT WORK FOR ME.

Comment 25

[Martijn Wargers (dead)]

David, this is worksforme on trunk, not on branch (which is what Firefox2.0.0.8 is)

Comment 26

[David Mischel]

I'll be danged: it does (Gran Paradiso alpha8). Terrific. WFM!

Comment 27

[John Daggett (:jtd)]

Attachment: screenshot, input method example

Sorry but I really think this needs to block.  The use of this popup is an absolute requirement for inputing Japanese text.  

The input method popup allows alternates to the primary choice to be selected.  For example, say you wanted to enter 化学(chemistry).  In Japanese this is inputted as "kagaku".  The word for science 科学 is spelled the same way.

With the input method enabled (on a Mac, choose 'Hiragana' on the keyboard menu), enter 'k'.  

Steps:

1. Switch the input method to Japanese (on a Mac, choose 'Hiragana' on the keyboard menu)
2. Enter 'k' (k with an underline appears)
3. Enter 'a' (か with underline appears)
4. Enter 'gaku' (かがく with underline appears)
5. Hit the spacebar once (科学 with underline appears)

This reflects the fact that 科学 is the most probable choice.

6. Hit spacebar again.  A popup now appears with other choices, including 化学.  Using the arrow keys allows you to choose another compound.
7. Select 化学 and hit enter twice, underline no longer appears.

This type of character input is *very* common with Japanese text, it is not a simple nicety.

Comment 28

[John Daggett (:jtd)]

oops, argh, wrong bug...

Comment 29

[Martijn Wargers (dead)]

For the curious mind, the comment was meant for bug 433340.