Firefox crashes when visiting http://www.reach.com/ The page loads fine with 2004092107 build crashes with 2005092208. talkback incidents: TB9635630Y TB9636160Q

First I could not get it to crash at all with Java and Flash enabled. But later it succeeded after emptying the cache everytime. No crash in 1.9a1_2005092110. Crash in 1.9a1_2005092123.

-> me I suppose

so in the PluginWndProc, msg=131 wParam=1 lParam=1243684 (0x0012fa24)

msg=WM_NCCALCSIZE

so I have 2093 stack frames here. It starts with nsView::ResetWidgetBounds (nsView.cpp:422) which goes briefly to win32 code, then to PluginWndProc where it starts to recurse.

wParam seems to actually be 0 (FALSE), not 1. The arguments are identical in all the PluginWndProc calls here. (including the HWND)

the RECT structure seems to have the contents: left top right bottom 3277736 0 0 511 which doesn't really make sense...

Do we somehow end up setting bogus stuff on a widget during nsObjectFrame::Reflow here? Can we figure out what the frame corresponding to the view we're calling ResetWidgetBounds is? And if it's the object frame, what does the plugin widget inside it look like?

a minimal testcase would be nice...

The external script file points to: http://secure-au.imrworldwide.com/v51.js

*** Bug 310528 has been marked as a duplicate of this bug. ***

*** Bug 310883 has been marked as a duplicate of this bug. ***

I presume the crash I'm seeing when loading http://www.hoyts.com.au is the same bug? It's only when I have Java enabled, and only in the Windows trunk browser (not in Mac or Moz 1.8 branch).

No idea, without a stack or talkback id.

(In reply to comment #14) > I presume the crash I'm seeing when loading http://www.hoyts.com.au is the same > bug? It's only when I have Java enabled, and only in the Windows trunk browser > (not in Mac or Moz 1.8 branch). I duplicated your crash. Looks like this bug to me. TB10749077K

*** Bug 313618 has been marked as a duplicate of this bug. ***

All of the applets demos on this page crashes with the same error. http://java.sun.com/applets/jdk/1.4/index.html Interestingly, the blink text demo doesn't.

*** Bug 311880 has been marked as a duplicate of this bug. ***

using html tag <applet> causes crash; using <embed> works fine.

awesome, thank you. What if you use src="..." instead of code="..." in the <embed> testcase?

minimal testcase does not crash broswer unless i have exytension Not minimised testcase causes crash

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051028 SeaMonkey/1.1a JRE 1.5.0_05, no flash, no blocking extensions Incident ID: 11208851 identical to talkbacks made on Bug 311933 and Bug 313212

You're right, minimal testcase only crashes with Adblock extension enabled. And fyi changing the <embed> attribute from code="..." to src="..." does stop the crashes. This new minimal testcase crashes without any extension enabled.

document.write('<script language="JavaScript" type="text/javascript" src="http://mozilla.org" />'); Eh... is that really needed to crash?

No. I was just playing around. It just need to be a valid url. :)

but such a <script> block is needed!?

Perhaps this will give a clue. I have 2 Winndows/XP systems. I have tried to get them configured as close as pollible but evidently there is a difference. On the first system the new minimal testcase crashes as advertised. On the second system it does not crash, but it runs the applet and then incorrectly displays the missing plugin toolbar. The plugin it says is missing is JRE. Perhaps fixing the plugin-finder issues will fix this crash as well?

OK, found the reason for this bug. There are various issues here. - That <script> tag is a child of the <applet> (this is not XHTML! <applet/> is not a closed tag) - When the <script> is parsed, frames are constructed. The <applet> didn't start to load yet - it only does that when all children are parsed - But the <applet> got a frame by now, because <applet> and <embed> default to eType_Plugin - Getting a frame while the type is plugin makes nsObjectLoadingContent post an event for asynchronous instantiate - But this isn't ready for instantiation yet! The type is "" and the uri is null - This causes instantiation of the nullplugin - At some point, we are done parsing the <applet>. This starts the real applet load. - this instantiates the applet synchronously. - So we have another plugin instantation for the same frame, and I didn't handle that case. ISSUES - The instantiate events should probably be cancelled when ObjectURIChanged is called again - embed/applet should not be of type eType_Plugin when mContentType/mURI aren't valid (maybe) - nsObjectFrame shouldn't screw up replacing plugins

I'll move event revoking to bug 314452 and attach a patch for the rest.

- adds some logging to nsObjectLoadingContent - calls (the new function) StopPlugin where needed - defaults all classes to eType_Loading

Comment on attachment 201384 [details] [diff] [review] patch >Index: content/base/src/nsObjectLoadingContent.cpp >+static PRLogModuleInfo* gObjectLog = PR_NewLogModule("objlc"); use PR_LOG_DEFINE instead? That'll do the #ifdef PR_LOGGING check for you and all. > nsObjectLoadingContent::OnStartRequest(n >+ LOG(("OBJLC [%p]: Request failed\n", this)); Include the string "OnStartRequest" somewhere in that message? >@@ -254,14 +274,15 @@ nsObjectLoadingContent::OnStartRequest(n >+ LOG(("OBJLC [%p]: Old type=%u New Type=%u\n", this, mType, newType)); Similar. >+ LOG(("OBJLC [%p]: OnStartRequest failed (%08x), falling back\n", this, rv)); "Listener OnStartRequest failed" > nsObjectLoadingContent::ObjectURIChanged(nsIURI* aURI, >+ LOG(("OBJLC [%p]: Loading object: URI=<%p> notify=%i type=<%s> forcetype=%i forceload=%i\n", >+ this, aURI, aNotify, aTypeHint.get(), aForceType, aForceLoad)); Should this log the URI spec? I guess it's not a big deal either way.... > nsObjectLoadingContent::NotifyStateChanged(ObjectType >+ LOG(("OBJLC [%p]: Notifying about state change: (%u, Log the value of aSync too? >Index: layout/generic/nsObjectFrame.cpp > nsObjectFrame::PrepareInstanceOwner() >+ StopPlugin(); That nulls out mInstanceOwner. > if (!mInstanceOwner) { So no need for this null-check. Given that this calls StopPlugin(), I don't think you need to call it in nsObjectLoadingContent. I assume you'll do the bfcache change to use StopPlugin() in a separate bug? r+sr=bzbarsky with the above addressed.

> Should this log the URI spec? I guess it's not a big deal either way.... I was thinking that the usual caller would be ObjectURIChanged, which already logs the spec. > So no need for this null-check. hm... I was thinking that StopPlugin() might some day be changed to keep the owner. but maybe that's not possible. OK, I'll change this.

filed Bug 314461 for making presshell use this

Checking in content/base/src/nsObjectLoadingContent.cpp; /cvsroot/mozilla/content/base/src/nsObjectLoadingContent.cpp,v <-- nsObjectLoadingContent.cpp new revision: 1.11; previous revision: 1.10 done Checking in content/base/src/nsObjectLoadingContent.h; /cvsroot/mozilla/content/base/src/nsObjectLoadingContent.h,v <-- nsObjectLoadingContent.h new revision: 1.4; previous revision: 1.3 done Checking in content/html/content/src/nsHTMLAppletElement.cpp; /cvsroot/mozilla/content/html/content/src/nsHTMLAppletElement.cpp,v <-- nsHTMLAppletElement.cpp new revision: 1.81; previous revision: 1.80 done Checking in content/html/content/src/nsHTMLSharedElement.cpp; /cvsroot/mozilla/content/html/content/src/nsHTMLSharedElement.cpp,v <-- nsHTMLSharedElement.cpp new revision: 1.58; previous revision: 1.57 done Checking in layout/generic/nsIObjectFrame.h; /cvsroot/mozilla/layout/generic/nsIObjectFrame.h,v <-- nsIObjectFrame.h new revision: 1.9; previous revision: 1.8 done Checking in layout/generic/nsObjectFrame.cpp; /cvsroot/mozilla/layout/generic/nsObjectFrame.cpp,v <-- nsObjectFrame.cpp new revision: 1.528; previous revision: 1.527 done Checking in layout/generic/nsObjectFrame.h; /cvsroot/mozilla/layout/generic/nsObjectFrame.h,v <-- nsObjectFrame.h new revision: 1.49; previous revision: 1.48 done

this reduced codesize by 28 byte! :-) (on luna)

I'm not sure if this is from this checkin or the checkin for bug 314461 (I applied the v2 patch to my source), but now Java applets don't seem to load at all. If I go to time.gov and select my timezone, the applet never even appears. On the bright side, Firefox doesn't crash, but I don't think that's how we want to fix it :P

(In reply to comment #40) > I'm not sure if this is from this checkin or the checkin for bug 314461 (I > applied the v2 patch to my source), but now Java applets don't seem to load at > all. If I go to time.gov and select my timezone, the applet never even appears. > On the bright side, Firefox doesn't crash, but I don't think that's how we want > to fix it :P > i am experiencing the same problem. while its nice that java applets no longer crash firefox, being able to actually use java would be nice. i tried a few different sites such as runescape.com and the games on java.com with the same results.

er, bug 314461 is not checked in yet. do you have an exact url to a java plugin that doesn't work?

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051031 Firefox/1.6a1 ID:2005103116 Just tested it on the Pacifica hourly shown above. I'm using Sun Java 5 Update 5 (1.5.0_05). It's an issue with Adblock Plus 0.5.10.20051030. Without Adblock installed (or with Adblock installed and disabled), applets load just fine (and Firefox doesn't crash!). With Adblock installed and enabled, nothing shows. For my testing, I'm using http://www.time.gov/timezone.cgi?Eastern/d/-5/java

If there is an issue with adblock, is it the same as bug 309076, basically? That is, does using the patched adblock pointed to in that bug help?

Adblock Plus 0.5.10.20051030 uses XPC Native Wrappers. I'll point mcm_ham to this discussion so he can weigh in on it, though.

Oh, wait. This is <object>. Trying to do anything scriptable with it flushes out reflow, does it not? That could be a tad annoying... ;) Biesi, how does our code deal with the content policy check flushing out all frame construction and reflow?

(In reply to comment #45) > Adblock Plus 0.5.10.20051030 uses XPC Native Wrappers. I'll point mcm_ham to > this discussion so he can weigh in on it, though. > Don't think I can help much, haven't delved into Mozilla code yet. But I can at least confirm that it still does this even after placing return 1 at the top of the ShouldLoad function.

time.gov doesn't work for me, keeps timing out. any other testcases? :)

http://www.en.zylom.com/game/91/alchemy.html Hit the "Play" link.

JavaScript error: , line 0: uncaught exception: [Exception... "Failure" nsresul t: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: http://game05.zylom.c om/servlet/Page?pageID=0&no-cache=1130851039728 :: showGame :: line 26" data: n o] That line is: parent.location = "/servlet/Content?pageID=2&no-cache=1130851168133"; are you sure this is related to this bug? also... I think someone should file a new bug for this

hmm, there seems to be an applet in the dom anyway...

nevermind, that applet is a "preloading" applet in an invisible iframe.

(that was without adblock fwiw)

The sites referenced all work just fine for me without adblock installed. I stopped running adblock about 1-1/2 year ago specifically because of issues with JAVA applets either not running, crashing, or taking 10 times longer to load than without adblock installed.

*** Bug 311668 has been marked as a duplicate of this bug. ***

Verified FIXED for me using Java Plug-in 1.5.0_04 with build SeaMonkey 1.1a:Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051102 Mozilla/1.0 on all testcases in this bug. Also, time.gov (http://www.time.gov/timezone.cgi?Eastern/s/-5/java) works just fine for me.

Well, as we've already said in this discussion, the problem only appears if you're using AdBlock.

Is there a followup bug on this adblock issue? If not, one should really be filed, and biesi and I cced...

http://cheniere.org/ the java program fails. Not running adblock.

time.gov isn't working either. Using Java 1.5.0_05 ... I get a "exception: java.lang.NullPointerException" in the status bar on both sites, before Loading Java App Failed, or sometimes Java app not inited.

http://cheniere.org/ and time .gov work just fine for me with Sun JAVA Version 1.5.0 (build 1.5.0_05-b05) and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051103 Firefox/1.6a1 ID:2005110305. I sugest a new profile and no extensions. IF that does not work please file a new bug and stop SPAMing this one.

(In reply to comment #58) > Is there a followup bug on this adblock issue? If not, one should really be > filed, and biesi and I cced... Bug 315841 has been filed.

Bug 358102 contains a similar stacktrace for Firefox 2.0. This bug is verified for 1.9a but seems to be not fixed for the 1.8 branch.

This bug was in trunk-only code.