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

RESOLVED WORKSFORME

Status

()

Core
Plug-ins
P2
critical
RESOLVED WORKSFORME
5 years ago
3 years ago

People

(Reporter: Loic, Unassigned)

Tracking

({hang, regression})

20 Branch
x86_64
Windows 7
hang, regression
Points:
---

Firefox Tracking Flags

(firefox19 unaffected, firefox20- affected, firefox21- affected, firefox22- affected)

Details

(crash signature, URL)

(Reporter)

Description

5 years ago
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.
(Reporter)

Updated

5 years ago
Keywords: regression, regressionwindow-wanted
(Reporter)

Updated

5 years ago
status-firefox19: --- → unaffected
tracking-firefox20: --- → ?
tracking-firefox21: --- → ?
tracking-firefox22: --- → ?

Comment 1

5 years ago
What does "Firefox hangs completely during reloading the Java applet" mean? Does Firefox recover after the applet is loaded?
(Reporter)

Comment 2

5 years ago
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

5 years ago
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

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

Updated

5 years ago
Severity: normal → critical
status-firefox20: --- → affected
status-firefox21: --- → affected
status-firefox22: --- → affected
Keywords: hang

Comment 5

5 years ago
The data we have thus far points to this being site-specific. TE?
tracking-firefox20: ? → -
tracking-firefox21: ? → -
tracking-firefox22: ? → -

Comment 6

5 years ago
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?

Updated

5 years ago
Keywords: regressionwindow-wanted → reproducible
(Reporter)

Comment 7

5 years ago
(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

Updated

5 years ago
Crash Signature: [@ @0x0 | __RtlUserThreadStart | _RtlUserThreadStart]

Comment 8

5 years ago
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
(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.
(Reporter)

Comment 10

5 years ago
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.
(Reporter)

Comment 11

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

Comment 12

5 years ago
> 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.
(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 ?
Can you still reproduce this on a recently nightly? I suspect it was fixed by bug 860490
Flags: needinfo?(epinal99-bugzilla)
(Reporter)

Comment 15

5 years ago
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.
Flags: needinfo?(epinal99-bugzilla)
(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.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Keywords: reproducible
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.