Closed Bug 489988 Opened 16 years ago Closed 15 years ago

Java Applets reload when print is called


(Core Graveyard :: Plug-ins, defect, P2)


(status1.9.2 beta1-fixed)

Tracking Status
status1.9.2 --- beta1-fixed


(Reporter: mike, Assigned: smaug)




(Keywords: regression, verified1.9.0.11, verified1.9.1)


(3 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/2009040821 Firefox/3.0.9
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/2009040821 Firefox/3.0.9

When trying to print a page which contains a Java applet, Firefox reloads the applet. This happens a split second before the page is actually printed. 

If you are using have your configuration set to show the preparing to print screen, you should observe this problem just as it appears. Please note that changing print.show_print_progress or any other print configuration does not appear to change the results.

Reproducible: Always

Steps to Reproduce:
 * Load Firefox 3.0.9
 * Go to
 * Allow the applet to load and starts displaying the time
 * Click on File->Print
 * Select your printer and then click OK

Actual Results:  
Applet reloads

Expected Results:  
The applet is unaffected and printing continues as normal.

The applet used in this example is very simple, but with a more complicated applet strange things happen. In an example that I cannot give due to it being a proprietary application, the applet reloading quickly causes Firefox to crash.

This was not a problem in 3.0.8, only in 3.0.9. Tested with Sun Java 1.4.2_19 and Sun Java 1.5.0_18. although I suspect it will happen with others.

Problem also reported at:
Confirmed on Windows XP. Regression range is
all from Olli Pettay. Maybe Bug 462517.
Component: General → Plug-ins
Ever confirmed: true
Keywords: regression
Product: Firefox → Core
QA Contact: general → plugins
Version: unspecified → Trunk
Flags: blocking1.9.2?
Flags: blocking1.9.1?
Flags: blocking1.9.0.11?
Flags: blocking1.9.0.10?
Attached patch patchSplinter Review
Uh, make sure the frame is alive but also check that the pointer is right.
We want to instantiate only if nsWeakFrame is for primary shell, like
I could probably change ::HasNewFrame to never create nsAsyncInstantiateEvent for print presshell, but this seems safer for branch.

Really sorry about this all.
Assignee: nobody → Olli.Pettay
Attachment #374542 - Flags: superreview?(roc)
Attachment #374542 - Flags: review?(roc)
Attached patch for 1.9.1Splinter Review
Attached patch for trunk (obsolete) — Splinter Review
Attached patch for trunkSplinter Review
Attachment #374546 - Attachment is obsolete: true
Attachment #374542 - Flags: superreview?(roc)
Attachment #374542 - Flags: superreview+
Attachment #374542 - Flags: review?(roc)
Attachment #374542 - Flags: review+
1.9.1 regression, blocking.
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P2
Target Milestone: --- → mozilla1.9.1
Comment on attachment 374542 [details] [diff] [review]

Either .10 or .11
Attachment #374542 - Flags: approval1.9.0.10?
Closed: 15 years ago
Resolution: --- → FIXED
Blocks: 462517
Conferred with Dan, and we're going to hold this for (end of May) so we can get 3.0.10 out asap.
Flags: blocking1.9.0.11?
Flags: blocking1.9.0.11+
Flags: blocking1.9.0.10?
Flags: blocking1.9.0.10-
Attachment #374542 - Flags: approval1.9.0.10? → approval1.9.0.11+
Comment on attachment 374542 [details] [diff] [review]

Approved for, a=dveditz for release-drivers
(we already have candidate builds for 3.0.10 being tested otherwise this would have been a righteous ride-along. But it's not a stop-ship.)
Whiteboard: needs-1.9.0-landing
Checking in content/base/src/nsObjectLoadingContent.cpp;
/cvsroot/mozilla/content/base/src/nsObjectLoadingContent.cpp,v  <--  nsObjectLoadingContent.cpp
new revision: 1.98; previous revision: 1.97
Keywords: fixed1.9.0.11
Whiteboard: needs-1.9.0-landing
verified FIXED on Shiretoko: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b5pre) Gecko/20090505 Shiretoko/3.5b5pre ID:20090505030932

This can't be verified on Trunk due to bug . Added dependency as a result.
Depends on: 485984
Verified fixed for with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: Gecko/2009051504 GranParadiso/3.0.11pre.
Verified fixed on trunk with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090520 Minefield/3.6a1pre
OS: Windows XP → All
Hardware: x86 → All
Target Milestone: mozilla1.9.1 → mozilla1.9.2a1
Flags: blocking1.9.2? → blocking1.9.2+
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.