User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206) Gecko/2009040821 Firefox/3.0.9 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.11) 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
Product: Firefox → Core
QA Contact: general → plugins
Version: unspecified → Trunk
I used this URL: http://www.jigzone.com/puzzles/2003-08-16
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.
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: approval18.104.22.168?
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Conferred with Dan, and we're going to hold this for 22.214.171.124 (end of May) so we can get 3.0.10 out asap.
Attachment #374542 - Flags: approval126.96.36.199? → approval188.8.131.52+
Comment on attachment 374542 [details] [diff] [review] patch Approved for 184.108.40.206, 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.)
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
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.
Verified fixed for 220.127.116.11 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:18.104.22.168pre) 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
You need to log in before you can comment on or make changes to this bug.