848392 - Firefox hangs completely if a Java applet is reloaded while java.exe is still running

Status: RESOLVED WORKSFORME

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

Description

[Loic]

Issue found during playing with the tescase of bug 836778.

STR:
1) Start a fresh profile with plugin Java(TM) Platform SE 7 U17.
2) Open https://qa01.enterprisewizard.com/gui2/login.jsp?keyID=0&KB=Demo&user=admin&passwd=qwerty&State=Main (accept the pop-up if need be)
3) Go to "Setup" > "Workflow" > Select "Support case" in the list and click "Edit" on the top 
Result: Java is launched to display a graph (cancel the pop-up if need be)
4) Close the tab
5) Apply steps #2 & #3

Result: Firefox hangs completely during reloading the Java applet.
If java.exe is killed in the process manager before step #5, it works normally.

Regression range:
m-c
good=2012-11-19
bad=2012-11-20
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4fddb9923ef0&tochange=bc69705c162d

My guess goes to Bug 800018.

Comment 1

[Benjamin Smedberg]

What does "Firefox hangs completely during reloading the Java applet" mean? Does Firefox recover after the applet is loaded?

Comment 2

[Loic]

No, Firefox starts to load the applet and becames blocked: tabs can't be switched, the window can't be closed etc. You need to kill Firefox.

Comment 3

[Alice0775 White]

It works as expected if UA was spoofing.
general.useragent.override = Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0

Comment 4

[Alice0775 White]

So, This bug is triggered by :
669ac8371d19	Alex Keybl — Merging in version bump NO BUG

Comment 5

[Alex Keybl [:akeybl]]

The data we have thus far points to this being site-specific. TE?

Comment 6

[Benjamin Smedberg]

Oh how I love version sniffing. Loic or Alice, can one of you run http://benjamin.smedbergs.us/crashfirefox.exe to kill the Firefox process and then report the crash (via the crashreporter) so that we can see the stack at the time of the hang?

This is probably the site or Java itself doing something dumb with "20". Does this happen with any java applet, or just some?

Comment 7

[Loic]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #6)
> Oh how I love version sniffing. Loic or Alice, can one of you run
> http://benjamin.smedbergs.us/crashfirefox.exe to kill the Firefox process
> and then report the crash (via the crashreporter) so that we can see the
> stack at the time of the hang?
> 
> This is probably the site or Java itself doing something dumb with "20".
> Does this happen with any java applet, or just some?

Not very useful, I guess. :/
CR with FF22: https://crash-stats.mozilla.com/report/index/bp-033e1e69-04b1-4b25-93c6-f46f32130307

Comment 8

[Alice0775 White]

FYI,
Regression window with force setting "general.useragent.override" = "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130306 Firefox/22.0"

Regression window(m-c)
Good:
http://hg.mozilla.org/mozilla-central/rev/ed47a41ba26a
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20111222 Firefox/12.0a1 ID:20111222031055
Bad:
http://hg.mozilla.org/mozilla-central/rev/c5b90ea7e475
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20111223 Firefox/12.0a1 ID:20111223032107
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ed47a41ba26a&tochange=c5b90ea7e475

Regression window(m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/ca4fa2862296
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20111221 Firefox/12.0a1 ID:20111221182558
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/8d4a9617fcd1
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20111221 Firefox/12.0a1 ID:20111221185737
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ca4fa2862296&tochange=8d4a9617fcd1

In local build,
Last Good: ca4fa2862296
First Bad: 9c7cc49f6556
Triggered by:
9c7cc49f6556	Jeff Walden — Bug 711647 - Add MOZ_DELETE to a bunch of deliberately-not-implemented methods across the tree. r=dbaron

Comment 9

[Georg Fritzsche [:gfritzsche]]

(In reply to Alice0775 White from comment #8)
> Triggered by:
> 9c7cc49f6556	Jeff Walden — Bug 711647 - Add MOZ_DELETE to a bunch of
> deliberately-not-implemented methods across the tree. r=dbaron

Hm, that seems unlikely - the changes there don't have any effect on Windows builds, unless i'm overlooking an unintended side-effect in that patch.
In fact the m-i pushlog looks unlikely.

Comment 10

[Loic]

My guess is the Java applet blocks the UI thread, like in this other Java demo (http://mylith.com/mozilla/832963/applet.html) where a modal window is open via the Java applet. If the modal window is not closed, the UI thread continues to be blocked, like in this current bug.
Maybe the UA sniffing script emphasizes the issue.

Comment 11

[Loic]

I tried with add-on UA Switcher and indeed, the hang is missing. Probably a TE bug with a bad US sniffing.

Comment 12

[Benjamin Smedberg]

> Not very useful, I guess. :/
> CR with FF22:
> https://crash-stats.mozilla.com/report/index/bp-033e1e69-04b1-4b25-93c6-f46f32130307

No that's actually pretty useful. We have java running a script (NPN_evaluate) which is running window.confirm(), which spins the event loop. The bottom of the stack is missing, but I can probably find it using other tools.

Comment 13

[John Schoenick [:johns]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #12)
> > Not very useful, I guess. :/
> > CR with FF22:
> > https://crash-stats.mozilla.com/report/index/bp-033e1e69-04b1-4b25-93c6-f46f32130307
> 
> No that's actually pretty useful. We have java running a script
> (NPN_evaluate) which is running window.confirm(), which spins the event
> loop. The bottom of the stack is missing, but I can probably find it using
> other tools.

Does that make this a dupe of bug 850191 ?

Comment 14

[John Schoenick [:johns]]

Can you still reproduce this on a recently nightly? I suspect it was fixed by bug 860490

Comment 15

[Loic]

I'm not able to reproduce the issue because the link of the demo has changed. And in comment 11, I was already not able to repro it. You can close it, I guess.

Comment 16

[John Schoenick [:johns]]

(In reply to Loic from comment #15)
> I'm not able to reproduce the issue because the link of the demo has
> changed. And in comment 11, I was already not able to repro it. You can
> close it, I guess.

Bug 860490 fixed the major cause of this, so I'm going to resolve -- please re-open if another way of triggering this is found.