156385 - Maximum Font size set to 12 prevents printing 2nd time in some cases

Status: RESOLVED WORKSFORME

(MailNews Core :: Printing, defect)

Description

[esther]

Using the 20020708 trunk build (found while testing printing bug fix 155430), on
linux if you set the preference for maximun font size to 12, if you receive a
mail message from a Windows system with aol.com attached you will get an error
after printing this message once.  The error message you will get is "You cannot
print while in print preview".  This does not happen to winxp, mac os10.1 or mac
os9.1 when changing this maximinum value from None to 12 in the same scenario.
This does not happen when receiving this type of message from a different linux
system, the same linux system, a mac OS10.1 or mac 9.1.

1. On your linux system, create a new profile and change the preference for
maximum font size to 12.  Preference found under Appearance|Fonts.
2. On a windows system, open aol.com in the browser and do a Send Page to the
mail account you have on your linux system.
3. Get and select the message on your linux system and Print it.
4. Print the message again

Result:  you get an error "You cannot print while in print preview" trying to
print that message again or any other message or browser pages.  You need to end
the app to be able to print again

Expected: It should print as many times as you want.

Note: This did not happen with the 7-2 branch build, I first noticed it when
testing the fix for 155430 using the 7-8 trunk build.

Comment 1

[esther]

changing assigned 

Comment 2

[Roland Mainz]

Sounds we leak the |nsDeviceContextPS| object somewhere... ;-(

What about filing a bug to get rid of all the manual refcounting in the
crossplatform print code (e.g. layout/, content/ etc.) to avoid such accidental
leaks ?

Comment 3

[esther]

update, there must be a condition within my winxp profile that contributes to
this bug because when I create a new profile on my winxp and send I don't see
the same problem in my linux profile with the max font size set to 12.  If
anyone else can reproduce this based on my steps above I would like to know. 
Again this done using a trunk build I haven't tested it with a current branch
build that contains the fix for 155430.  

Comment 4

[esther]

I tested this with 7-9 branch builds that contain the fix for 155430 and they
are all OK. No problems with this scenario on branch. 

Comment 5

[Wayne Mery (:wsmwk)]

does comment 4 mean this also was fixed on trunk?
anyone still see this?
[pre-reorg cleanup]

Comment 6

[Wayne Mery (:wsmwk)]

Pedro, does this reproduce for you?

Comment 7

[Pedro Garcia Rodriguez]

(In reply to Wayne Mery (:wsmwk) from comment #6)
> Pedro, does this reproduce for you?

Wayne in wich version should I try it?... As soon as I arrive home I can test it!

Comment 8

[Wayne Mery (:wsmwk)]

(In reply to Pedro Garcia Rodriguez from comment #7)
> (In reply to Wayne Mery (:wsmwk) from comment #6)
> > Pedro, does this reproduce for you?
> 
> Wayne in wich version should I try it?... As soon as I arrive home I can
> test it!

any current code branch, released or not released, will do

Comment 9

[Phoenix]

Resolved per whiteboard