Java Applets reload when print is called

VERIFIED FIXED in mozilla1.9.2a1

Status

()

defect
P2
major
VERIFIED FIXED
10 years ago
10 years ago

People

(Reporter: mike, Assigned: smaug)

Tracking

({regression, verified1.9.0.11, verified1.9.1})

Trunk
mozilla1.9.2a1
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.2 +
blocking1.9.1 +
blocking1.9.0.10 -
blocking1.9.0.11 +

Firefox Tracking Flags

(status1.9.2 beta1-fixed)

Details

()

Attachments

(3 attachments, 1 obsolete attachment)

Reporter

Description

10 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.9) Gecko/2009040821 Firefox/3.0.9
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.9) 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 http://www.time.gov/timezone.cgi?Eastern/d/-5/java
 * 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:
http://support.mozilla.com/tiki-view_forum_thread.php?locale=nl&forumId=1&comments_parentId=334847
Confirmed on Windows XP. Regression range is http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0d300ab7a8cf&tochange=4861194a5ed6
all from Olli Pettay. Maybe Bug 462517.
Status: UNCONFIRMED → NEW
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?
Posted 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
GetExistingFrame().
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
Status: NEW → ASSIGNED
Attachment #374542 - Flags: superreview?(roc)
Attachment #374542 - Flags: review?(roc)
Posted patch for trunk (obsolete) — Splinter Review
Posted 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]
patch

Either .10 or .11
Attachment #374542 - Flags: approval1.9.0.10?
http://hg.mozilla.org/mozilla-central/rev/b90d16b20088
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Blocks: 462517
Conferred with Dan, and we're going to hold this for 1.9.0.11 (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]
patch

Approved for 1.9.0.11, 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.)
Duplicate of this bug: 490082
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
done
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 https://bugzilla.mozilla.org/show_bug.cgi?id=485984 . Added dependency as a result.
Depends on: 485984
Verified fixed for 1.9.0.11 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.11pre) 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
Status: RESOLVED → VERIFIED
OS: Windows XP → All
Hardware: x86 → All
Target Milestone: mozilla1.9.1 → mozilla1.9.2a1
Flags: blocking1.9.2? → blocking1.9.2+
You need to log in before you can comment on or make changes to this bug.