315111 - java real estate tour app hangs recent firefox 1.5 builds

Status: RESOLVED INVALID

(Core Graveyard :: Java: OJI, defect)

Description

[chris hofmann]

moving from e-mail thread to the bug system started by brendan.

Tim Riley wrote:
> Marcia,
>
> Here is an interesting listing and graphic test:
>
> http://tours.tourfactory.com/tours/tour.asp?t=223372&sreferer=www.mlslistings.com&home=www.mlsli
>
> You can chose between html, flash,  and java (both flat and bubble rendering) and there are a ton of views to use.  I guess if you own a $9M house you revel in the technology! ;)
> I tried this in XP.  You want to try on MaxOS?


On 4-Nov-05, at 11:34 AM, Chris Hofmann wrote:

> Darin Fisher wrote:
>> I loaded that site, clicked on the Java (bubble) view, and then the Java (flat) view, and FF appeared to hang.  This was on WinXP (sp2) with the latest 1.8 branch build of FF.
>>
>> -Darin
>>
> Same for me on beta 2 - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051025 Firefox/1.5

Ditto here on Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051025 Firefox/1.5.  Clicking from bubble to flat caused a hang.

~ deb

Comment 1

[chris hofmann]

my java version info says Version 1.5.0 (build 1.5.0_04-b05)

Comment 2

[chris hofmann]

also has an old seamonkey build I had laying around, so this might have never worked.
Mozilla 1.8b2  - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050310

anyone have firefox 1.0.x handy?

Comment 3

[chris hofmann]

> Comment #2 From chris hofmann  2005-11-04 10:06 PST  [reply] -------
>
> also has 

also hangs

Comment 4

[Scott MacGregor]

The talback report on the mac shows a crash in:


libhotspot.dylib.1.0.0 + 0x237740 (0x938a4740)

Brendan says that's the HotSpot optimizing JVM.

Comment 5

[Deb Richardson [:dria] (plz NEEDINFO)]

I cannot replicate the earlier hang on my regular profile.  The first time I went to the site it displayed the "HTML (Flat)" version first, then I switched to "Java (Bubble)" then hanged when I switched to "Java (Flat)".  Since that point every attempt I've made to use that url has worked fine, even after clearing cache, history, cookies, etc.

I replicated it finally by creating a new profile:

1) Create new profile "JT1"
2) Go to http://tours.tourfactory.com/tours/tour.asp?t=223372&sreferer=www.mlslistings.com&home=www.mlsli
3) It starts on "HTML (Flat)".  Click to "Java (Bubble)".
4) Click to "Java (Flat)"
5) Hangs

Tried again, another new profile:

1) Create new profile "JT2"
2) Go to http://tours.tourfactory.com/tours/tour.asp?t=223372&sreferer=www.mlslistings.com&home=www.mlsli
3) Starts on "HTML (Flat)".  Click to "Java (Flat)".
4) Click to "Java (Bubble)"
5) Hangs

Restarted Firefox using the profile that just hanged.

1) Start Firefox using "JT2" profile
2) Go to http://tours.tourfactory.com/tours/tour.asp?t=223372&sreferer=www.mlslistings.com&home=www.mlsli
3) Site remembered settings and starts on "Java (Bubble)"
4) Click to "Java (Flat)" no problems
5) Site works fine switching between all view types several times.

Finally, another new profile to verify:

1) Create profile "JT3"
2) Go to http://tours.tourfactory.com/tours/tour.asp?t=223372&sreferer=www.mlslistings.com&home=www.mlsli
3) Starts on "HTML (Flat)".  Click to "Java (Bubble)".  Displays fine.
4) Click to "Java (Flat)".
5) Hangs.

Firefox:

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051025 Firefox/1.5

Plugins:

Java Plug-in
File name: Java Applet.plugin
Java 1.3.1 Plug-in

Java Plug-in (CFM)
File name: Java Applet Plugin Enabler
Java 1.3.1 Plug-in (CFM)

OJI Plugin for Mac OS X, v1.0
File name: MRJPlugin.plugin
Runs Java applets using the <APPLET>, <OBJECT> and <EMBED> HTML elements.

Comment 6

[Jack Lu]

Can anyone try the same thing on Windows XP and JRE 1.5.0 or later?

Comment 7

[Deb Richardson [:dria] (plz NEEDINFO)]

I managed to get a talkback on hang: TB11454347K

And my JRE info is:

java version "1.4.2_09"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_09-232)
Java HotSpot(TM) Client VM (build 1.4.2-54, mixed mode)

Comment 8

[Darin Fisher]

> Can anyone try the same thing on Windows XP and JRE 1.5.0 or later? 

I was using Windows XP and JRE 1.5.0_2 when I observed the hang.

Comment 9

[Bob Clary [:bc] (inactive)]

(In reply to comment #6)
> Can anyone try the same thing on Windows XP and JRE 1.5.0 or later?

Windows XP, Java 1.5.0_05 hangs (choose java flat then java bubble)

Comment 10

[Mike Beltzner [:beltzner, not reading bugmail]]

I dug into this a little (using OS X) with a computer that has both J2SE 1.4.2 and J2SE 5.0 installed, Java Embedding Plugin 0.9.5, Java Plug-in (CFM) 1.3, and Java Plug-in 1.3.

Trying to reproduce Deb's steps in comment 5, I found the following:
  - didn't hang with my default profile (migrated from Beta1->RC1)
  - didn't hang on first time with fresh profile "j"
  - always hung on subsequent attempts with profile j
  - now always hangs on my default profile.

I filed talkback indicents TB11454526H and TB11454778Z. In addition, I collected the following console output:

First time it crashed ...
### MRJPlugin:  getPluginBundle() here. ###
### MRJPlugin:  CFBundleGetBundleWithIdentifier() succeeded. ###
### MRJPlugin:  CFURLGetFSRef() succeeded. ###
2005-11-04 15:05:00.060 firefox-bin[19930] JEP creating applet ptviewer (http://tours.tourfactory.com/tours/)
PTViewer v. 2.5  © H. Dersch, [e-mail]
2005-11-04 15:05:00.380 firefox-bin[19930] WARNING: _wrapRunLoopWithAutoreleasePoolHandler got kCFRunLoopExit, but there are no autorelease pools in the stack.
CGContextFlush: invalid context
2005-11-04 15:05:16.025 firefox-bin[19930] An irrecoverable stack overflow (bypassing yellow and red zones).
2005-11-04 15:05:16.025 firefox-bin[19930]

Subsequent times it crashed ...
beltzner:/Applications/Firefox.app/Contents/MacOS 15:05:16$ ./firefox-bin -P j
### MRJPlugin:  getPluginBundle() here. ###
### MRJPlugin:  CFBundleGetBundleWithIdentifier() succeeded. ###
### MRJPlugin:  CFURLGetFSRef() succeeded. ###
2005-11-04 15:11:09.302 firefox-bin[19944] JEP creating applet ptviewer (http://tours.tourfactory.com/tours/)
PTViewer v. 2.5  © H. Dersch, [e-mail]
2005-11-04 15:11:09.654 firefox-bin[19944] WARNING: _wrapRunLoopWithAutoreleasePoolHandler got kCFRunLoopExit, but there are no autorelease pools in the stack.
CGContextFlush: invalid context
Bus error

Comment 11

[Hermann Schwab]

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051103 SeaMonkey/1.1a
I've seen the base URL crashing in Bug 312495 crash when exiting a page with Java Bubble viewer, today it is only hanging. Maybe the fix of Bug 309706
stack overflow crash [@ jpinscp.dll + 0xaa87] changed it from crash to hang.

It was crashing if you changed from bubble to bubble, or elsewhere.
The progress is, now it doesn't crash, it only hangs, without giving clues via talkback.

Comment 12

[Scott MacGregor]

some of the talkback reports filed by Deb and others are showing up on the talkback server now.

One of them shows lots of frame destruction going on before eventually dying in:
nsPluginInstanceOwner::Destroy

Comment 13

[Steven Michaud [:smichaud] (Retired)]

Attachment: Crashes in Mac OS X 10.4.3

I tested Firefox 1.5 RC1 on Mac OS X 10.2.8, 10.3.9 and 10.4.3.  I
didn't see any crashes on 10.2.8 and 10.4.3.  But I _did_ see crashes
on 10.4.3 when moving between the two different Java "tours".

I've attached five crash logs, all in one file.  All of my crashes
take place in the context of destroying a Java plugin instance (using
a call to MRJPluginInstance::Destroy()), but they don't necessarily
all take place on thread 0.

I think it's pretty clear that there's a Firefox bug here (or bugs).
But on OS X the bug(s) may be triggered by something done by the Java
Embedding Plugin -- the JEP stops applets differently on OS X 10.4.X
than it does on other versions of Mac OS X, and an applet is always
stopped just before it's destroyed.

Comment 14

[Steven Michaud [:smichaud] (Retired)]

> I didn't see any crashes on 10.2.8 and 10.4.3.

I meant to say that I didn't see any crashes on 10.2.8 and 10.3.9.

Comment 15

[Hermann Schwab]

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051103 SeaMonkey/1.1a
JRE 1.5.0_05

two steps to get a crash or hang:

1. Load 'Front' in Bubble Viewer, wait until it is working.
http://tours.tourfactory.com/tours/Tour.asp?t=223372&home=http%3A%2F%2Fwww%2Emlsli&slink=%2D2&af=1&sc=1444722&s=1

2. Click 'Front' tab, crash or hang.

TB11473524M, TB11473514Q, TB11472744Z

If Firefox hangs, the applet has been ended normally, Firefox is running consuming 1% CPU, doesn't respond. When I close Firefox, Java Icon stays. I've got to kill Firefox with Process Explorer, then Java also quits.

Comment 16

[Mike Schroepfer]

Roc or DBaron - given the top of the stack in the crashes (nsBlockFrame::Reflow*) is it possible either one of you could take a look and vector elsewhere if necessary?

Comment 17

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Has anyone hit that stack in a debug build?  If so, did you hit the "about to crash due to bug 136927" first?

Comment 18

[Darin Fisher]

(In reply to comment #17)
> Has anyone hit that stack in a debug build?  If so, did you hit the "about to
> crash due to bug 136927" first?

I just tried, and no, I didn't see that on the console (using a debug 1.8 branch build of FF on WinXP).

The stack trace that I ended up with is a bit different.  I'll post it along with some other info shortly.

Comment 19

[Darin Fisher]

Attachment: Stack trace and variable dump for crash on WinXP w/ 1.8 branch build

Comment 20

[Tim Riley [:timr]]

It looks like this bug has been around for a while.  I just tried FF 1.0.7 and it has the same problem.  Since there have been not other crash reports like this since 1.0.7 shipped, this seem like an isolated problem.

Comment 21

[Asa Dotzler [:asa]]

we believe that this is fairly isolated and probably inside of Java. 

Comment 22

[Jack Lu]

Are we sure this is a bug inside Java? Based on the stack trace attached by Darin (comment #19), it looks like we uncovered a bug inside the frame layout code. 

Comment 23

[Brendan Eich [:brendan]]

Asa: not sure what you mean by "isolated" -- this bug may bite only a few users, but it crashes or hangs Firefox, so there's no process-like isolation of bad effects to the plugin alone.  Darin pointed out problems with games.yahoo.com, and there are other applet-heavy sites than these two classes (games, vtours).

This is a severe enough bug that I think we should do something for 1.5, not in our code, but in making sure that people have a fixed Java plugin.

The question is, what is the bug on file with Sun folks for these Java plugin crashes we have reported?  Can we link to it, or at least record its (inside the firewall) id here?  We need to know what Java plugin release will fix this bug, or these bugs, and then do something with our plugin finder service, release notes, and whatever else we can use post-1.5, to help users avoid the bad Java plugin versions.

If there's a Firefox bug to blame too, or alone, then we'll apologize for laying blame on the Java plugin (although given the crashes I've seen, there must be at least a profound lack of robustness in the face of the hypothetical Firefox or Gecko bug).  But right now, it looks like a Java plugin bug, as you wrote.  So what are we (all) going to do about it?

/be

Comment 24

[Brendan Eich [:brendan]]

(In reply to comment #22)
> Are we sure this is a bug inside Java? Based on the stack trace attached by
> Darin (comment #19), it looks like we uncovered a bug inside the frame layout
> code. 

Hi Xiaobin,

Yes, we are sure there is a bug (not necessarily the only bug) in the Java plugin, since we have a reproducible crash on Windows XP that is within the plugin (the stack is actually deep in the MSCRT and NTDLL runtimes, but from the Java plugin code, which is active deeper on the stack).

Any Gecko frame or line list crash is ours to fix, but it is not the first thing that goes wrong in the reproducible testcase.  I watched mrbkap reproduce, and the first thing that happened was the Java plugin dying on a thread of its own.  Later the process crashed, but if there was heap corruption, almost anything could crash.  That would not, in general, show a bug anywhere but in the code that corrupted the heap, which is likely the code runninng in the first thread that crashed: the Java plugin.

/be

Comment 25

[Brendan Eich [:brendan]]

(In reply to comment #24)
> Later the process crashed, but if there was heap
> corruption, almost anything could crash.  That would not, in general, show a
> bug anywhere but in the code that corrupted the heap, which is likely the code
> runninng in the first thread that crashed: the Java plugin.

Of course, what I wrote *could* apply in the other way: Gecko or Firefox code corrupts the heap, the Java plugin stumbles over the corruption, the plugin thread dies, then Firefox dies.  This is possible, but I think less likely, given that the reproduce-by steps involve plugin interactions.

We really could use symbols, if not a debug-built plugin, in order to help find out what is going wrong under a debugger, with valgrind or purify, etc.  Without plugin source and debugability, it's up to Sun folks to reproduce this and debug both the plugin code and Firefox.  It's easy to reproduce.  So again, I think we need a Sun bug and some help from Sun Java plugin owners.

/be

Comment 26

[Jack Lu]

I am trying to reassign this bug to Danielle, but I found I don't have the previledge anymore. All I can see is "Leave as NEW". Could someone check the permissions we have. We should have to permission to reassign the bugs.Thanks.

Comment 27

[Darin Fisher]

>   Darin pointed out problems with
> games.yahoo.com, and there are other applet-heavy sites than these two classes
> (games, vtours).

Correction: I said that games.yahoo.com is a site that makes extensive use of Java and would therefore make a good testcase.  I don't know of any problems with any of those games, but I haven't tested them (all) myself.

Comment 28

[Scott MacGregor]

(In reply to comment #27)
> >   Darin pointed out problems with
> > games.yahoo.com, and there are other applet-heavy sites than these two classes
> > (games, vtours).
 

I spent part of lunch playing various JAVA based games on games.yahoo.com on the Mac using the RC2 build. Most of the games had warnings saying "this game will not run on Unix or Macintosh systems". But they all worked fine for me :)

Other than realizing how much fun backgammon is, the various card, board and arcade style games I tried all worked without showing the problems I get on the real estate tour app.

So far we haven't come up with other sites running into this problem besides Brendan's java real estate tour app. Marcia has spent time on some of the other java based gaming sites and Tim spent some time looking at other real estate based java tour sites I believe. 

Although we can't claim to have tried every JAVA related site. I guess I should be thankful I'm not looking for real-estate right now using RC2 :)

Comment 29

[Brendan Eich [:brendan]]

Darin: sorry, i misread your mail on the games thing.

Mscott: the hangs that caused me to send the initial mail I sent were afflicting more than one vtour, althouth the reproducible one id'ed by Tim a big help (there are too many bad vtour sites and I don't even remember all of the ones that hung; you are better off playing games than I am house-shopping, I think I'll join you for backgammon ;-).

Xiaobin, I'll restore your editbugs capability -- I think you lost that in some eng.sun.com vs. sun.com bugzilla login id change.

/be

Comment 30

[timeless]

[e-mail] has canconfirm and editbugs. since you can't keep track of your accounts, i'm not confident enough in you to grant them for another account of yours.

Comment 31

[Brendan Eich [:brendan]]

timeless: butt out.

/be

Comment 32

[Adam Guthrie]

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

Comment 33

[Jack Lu]

I can reproduce the hang with both JRE 1.5.0_07 and latest jdk 6 build. I saw jvm.dll in the stack, so I assume plug-in team should take a look at least. I filed a Sun internal bug (6348224) for this issue. Danielle, would you please ask someone to take a look at this bug? This seems working fine with IE, but hangs firefox on Windows XP Professional w/ SP2 consistently. Thanks. 

Comment 34

[danielle.pham]

(In reply to comment #33)

I was able to reproduce problem with applet in http://tours.tourfactory.com/tours/tour.asp?t=223372&sreferer=www.mlslistings.com&home=www.mlsli
on WinXP SP2.

There seems to be a race condition between AppletPanel.createAppletThread() and AppletPanel.getClassLoader().  I'm reassigning Sun's Bug id 6348224 to AWT team and will continue to work with them on this problem. 

Comment 35

[Mike Lei]

It seems a browser bug.  Firefox cannot do with page in which <table> is nested in  <div>.  Two files are attached:

tour-good.html :  when click "Click here", the home page of SUN can be loaded successfully.

tour-bad.html:    when click "Click here", firefox hangs.

Comment 36

[Mike Lei]

Attachment: firefox doesn't hang with this page

Comment 37

[Mike Lei]

Attachment: firefox hangs with this page

Comment 38

[Bill Gianopoulos [:WG9s]]

(In reply to comment #37)
> Created an attachment (id=203248) [edit]
> firefox hangs with this page
> 

This attachment does not cause a hang for me with either Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051113 Firefox/1.6a1 ID:2005111305 or Firefox 1.5 RC2.  This is with JAVA Version 1.5.0 (build 1.5.0_05-b05).

I do see the issue with the originally reported URL in both Firefox versions.

Is there something specific that need to be done when testing with this attachment to cause the hang?

Comment 39

[Mike Lei]

> 
> This attachment does not cause a hang for me with either Mozilla/5.0 (Windows;
> U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051113 Firefox/1.6a1 ID:2005111305
> or Firefox 1.5 RC2.  This is with JAVA Version 1.5.0 (build 1.5.0_05-b05).
> 
My firefox version is Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051107 Firefox/1.5.  Java is 1.5.0_05-b05
> I do see the issue with the originally reported URL in both Firefox versions.
> 
> Is there something specific that need to be done when testing with this
> attachment to cause the hang?
Do you disabed JavaScript?  If JavaSCript is disabled, the above link doesn't hang.  If JavaSCript is enable, when you click "Click Here" in https://bugzilla.mozilla.org/attachment.cgi?id=203248&action=view,  is the page of http://www.sun.com loaded successfully ?

 

Comment 40

[Pete Zha]

> This attachment does not cause a hang for me with either Mozilla/5.0 (Windows;
> U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051113 Firefox/1.6a1 ID:2005111305
> or Firefox 1.5 RC2.  This is with JAVA Version 1.5.0 (build 1.5.0_05-b05).
> 
> I do see the issue with the originally reported URL in both Firefox versions.
> 
> Is there something specific that need to be done when testing with this
> attachment to cause the hang?
> 

You need to click "click here" link in this attachment to reproduce the hang

Comment 41

[Bill Gianopoulos [:WG9s]]

(In reply to comment #39)
> > 
> > This attachment does not cause a hang for me with either Mozilla/5.0 (Windows;
> > U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051113 Firefox/1.6a1 ID:2005111305
> > or Firefox 1.5 RC2.  This is with JAVA Version 1.5.0 (build 1.5.0_05-b05).
> > 
> My firefox version is Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8)
> Gecko/20051107 Firefox/1.5.  Java is 1.5.0_05-b05
> > I do see the issue with the originally reported URL in both Firefox versions.
> > 
> > Is there something specific that need to be done when testing with this
> > attachment to cause the hang?
> Do you disabed JavaScript?  If JavaSCript is disabled, the above link doesn't
> hang.  If JavaSCript is enable, when you click "Click Here" in
> https://bugzilla.mozilla.org/attachment.cgi?id=203248&action=view,  is the page
> of http://www.sun.com loaded successfully ?
> 
> 
> 

It fails today, but did not fail the last time I tried not sure why.  State of the cache? or perhaps different itneraction with the tour.  I could not make it fail the day I posted the comment that I could not get the testcase to fail.  Yes I did click where it says Click here.

It seems to hang every time today.

Comment 42

[Bill Gianopoulos [:WG9s]]

OK I figured out why I could not get it to hang on the first try.

If you just run the second testcase (the hang one) it hangs.

If you run the first testcase, then hit the back button until you get back to the bug then click on the ohter atachment link it runs fine, no hang.

Comment 43

[Mike Lei]

(In reply to comment #42)
> OK I figured out why I could not get it to hang on the first try.
> 
> If you just run the second testcase (the hang one) it hangs.
> 
> If you run the first testcase, then hit the back button until you get back to
> the bug then click on the ohter atachment link it runs fine, no hang.
> 
It still hangs on my side. I did below
1. load https://bugzilla.mozilla.org/show_bug.cgi?id=315111
2. click https://bugzilla.mozilla.org/attachment.cgi?id=203247&action=view
3. click "Click here" in that page, the homepage of SUN is loaded successfully
4. click "Back" until seeing https://bugzilla.mozilla.org/show_bug.cgi?id=315111
5. click https://bugzilla.mozilla.org/attachment.cgi?id=203248&action=view
6. click "Click here" in that page, hang here.

Anyway, these two testcase are very similar. the only difference is <table> is used in hanging testcase. Could mozilla engineers look into this issue ?

Comment 44

[Hermann Schwab]

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051116 SeaMonkey/1.5a
JRE1.5.0_05
Talkback ID: TB11950326W

1. load Attachment 203248 [details] firefox hangs with this page
2. click the link 'click here'

Result: Seamonkey sort of hangs, CPU load and memory usage are low and constant, you can switch between tabs and windows, scroll, new tabs can be created, but don't finish loading the empty page, links don't load, the hourglass is shown.
Once testing this I got a crash, couldn't repeat.

Comment 45

[danielle.pham]

(In reply to comment #44)

Thank you all for the different testcases.  We were able to reproduce both the hang and the crash that you mentioned on WinXP.
The problem is not caused by applet being invoked within a <table> defined in a <div> block.  Rather, it is because window event being mishandled during our java applet shutdown.  The nested <table> in <div> block somehow just aggrevates the problem even more.

Anyway, Mike Lei and I found a fix for the problem in JPI.  With this fix, we ran through the testcases and no longer see any more hang or crash.
We will proceed putting this fix in the earliest possible patch for Java 1.5.0.

Meanwhile, if you're interested, we can try to see if we can send you a test binary so that you can proceed with your firefox 1.5 testing.  Let us know.

Comment 46

[Jason Bassford]

Nothing in the Mozilla code itself was actually changed.

-> WORKSFORME

Comment 47

[Jason Bassford]

Ack!  Wrong button.  Sorry about the spam.

Comment 48

[Hermann Schwab]

Reopening

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8) Gecko/20051210 Firefox/1.5
Java(TM) 2 Platform Standard Edition 5.0 Update 6

with Java bubble viewer crash when switching to another java bubble view.

Talkback Incident ID: 12816766 
nsBlockFrame::DoRemoveFrame  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/generic/nsBlockFrame.cpp, line 5730]
nsBlockFrame::RemoveFrame  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/generic/nsBlockFrame.cpp, line 5510]
nsFrameManager::RemoveFrame  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsFrameManager.cpp, line 705]
nsCSSFrameConstructor::ContentRemoved  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 9965]
PresShell::ContentRemoved  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsPresShell.cpp, line 5514]
nsDocument::ContentRemoved  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/base/src/nsDocument.cpp, line 2400]
nsGenericElement::RemoveChildAt  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/base/src/nsGenericElement.cpp, line 2840]
nsGenericElement::RemoveChild  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/base/src/nsGenericElement.cpp, line 3720]
nsRange::DeleteContents  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/base/src/nsRange.cpp, line 1593]
nsGenericHTMLElement::SetInnerHTML  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/html/content/src/nsGenericHTMLElement.cpp, line 936]
nsGenericHTMLElementTearoff::SetInnerHTML  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/html/content/src/nsGenericHTMLElement.cpp, line 214]
XPCWrappedNative::CallMethod  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2139]
XPC_WN_GetterSetter  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1468]
js_Invoke  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1177]
js_InternalInvoke  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1274]
js_InternalGetOrSet  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1333]
js_SetProperty  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsobj.c, line 3024]
js_Interpret  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 3360]
js_Invoke  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1197]
js_InternalInvoke  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1274]
JS_CallFunctionValue  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsapi.c, line 4158]
nsJSContext::CallEventHandler  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/dom/src/base/nsJSEnvironment.cpp, line 1411]
nsJSEventListener::HandleEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/dom/src/events/nsJSEventListener.cpp, line 195]
nsEventListenerManager::HandleEventSubType  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/events/src/nsEventListenerManager.cpp, line 1685]
nsEventListenerManager::HandleEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/events/src/nsEventListenerManager.cpp, line 1786]
nsGenericElement::HandleDOMEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/base/src/nsGenericElement.cpp, line 2169]
nsGenericHTMLElement::HandleDOMEventForAnchors  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/html/content/src/nsGenericHTMLElement.cpp, line 1491]
nsHTMLAnchorElement::HandleDOMEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/html/content/src/nsHTMLAnchorElement.cpp, line 295]
nsGenericElement::HandleDOMEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/base/src/nsGenericElement.cpp, line 2198]
nsHTMLImageElement::HandleDOMEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/html/content/src/nsHTMLImageElement.cpp, line 507]
PresShell::HandleEventInternal  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsPresShell.cpp, line 6367]
PresShell::HandleEventWithTarget  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsPresShell.cpp, line 6265]
nsEventStateManager::CheckForAndDispatchClick  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/events/src/nsEventStateManager.cpp, line 3039]
nsEventStateManager::PostHandleEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/events/src/nsEventStateManager.cpp, line 2016]
PresShell::HandleEventInternal  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsPresShell.cpp, line 6439]
PresShell::HandleEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsPresShell.cpp, line 6203]
nsViewManager::HandleEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/view/src/nsViewManager.cpp, line 2559]
nsViewManager::DispatchEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/view/src/nsViewManager.cpp, line 2246]
HandleEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/view/src/nsView.cpp, line 174]
nsWindow::DispatchEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/widget/src/windows/nsWindow.cpp, line 1252]
nsWindow::DispatchMouseEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/widget/src/windows/nsWindow.cpp, line 5982]
ChildWindow::DispatchMouseEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/widget/src/windows/nsWindow.cpp, line 6233]
nsWindow::WindowProc  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/widget/src/windows/nsWindow.cpp, line 1434]
KERNEL32.DLL + 0x363b (0xbff7363b)
KERNEL32.DLL + 0x242e7 (0xbff942e7)
0x00d18b62


Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051208 SeaMonkey/1.5a
TB12813962K

For your convenience:    JRE 5.0 Update 6  available there:
http://java.sun.com/j2se/1.5.0/download.jsp

Comment 49

[Brendan Eich [:brendan]]

New bug?  Not the same stack I saw over someone's shoulder.

/be

Comment 50

[Hermann Schwab]

(In reply to comment #49)
> New bug?  Not the same stack I saw over someone's shoulder.
> 
> /be
> 

It's not a new bug, I'll reopen with current Talkbacks
Bug 312495 crash when exiting a page with Java Bubble viewer

I also saw the hang here with Attachment 203248 [details] firefox hangs with this page

Comment 51

[Adam Guthrie]

[e-mail], did this fix make it into JRE 5.0 Update 6?

Comment 52

[danielle.pham]

(In reply to comment #51)
> [e-mail], did this fix make it into JRE 5.0 Update 6?
> 

No, Fix is not in JRE 5.0 U6. At the time this bug was filed, U6 was already closed. This fix will be in JRE 5.0 U7 (GA planned on 3/30/06).  If you want to try U7 B1, must wait until 1/11/06 for U7 b1 promotion.

If it's a new problem, please open a new bug.  Otherwise, please keep this bug closed.

Comment 53

[Jason Bassford]

Again, no code was actually checked into Mozilla.  Either WORKSFORME or this bug should have been filed under Tech Evangelism.

->WORKSFORME

Comment 54

[Bill Gianopoulos [:WG9s]]

(In reply to comment #53)
> Again, no code was actually checked into Mozilla.  Either WORKSFORME or this
> bug should have been filed under Tech Evangelism.
> 
> ->WORKSFORME
> 

You are confused.  This problem is with the SUN JAVA plug-in NOT with the website.  Therefore Tech Evangelism is NOT appropriate.

Also WORKSFORME is not appropriate either as that maens that the bug cannot be duplicated (which it obviously can).

The correct resolution for bugs opened on Mozilla where the probelm turns out to be external is INVALID.