Closed Bug 832963 Opened 8 years ago Closed 7 years ago

Browser freezes when java applet calls showDocument()

Categories

(Core :: Plug-ins, defect, P3)

18 Branch
x86
Windows 7
defect

Tracking

()

VERIFIED FIXED
mozilla25
Tracking Status
firefox18 --- affected
firefox19 --- affected
firefox20 --- affected
firefox21 --- affected
firefox22 --- affected
firefox23 --- affected
firefox24 --- verified
firefox25 --- verified
firefox-esr17 --- unaffected

People

(Reporter: mylith+mozilla, Unassigned)

References

()

Details

(Keywords: hang, regression, testcase)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0
Build ID: 20130116073211

Steps to reproduce:

Hello,

I just experienced really annoying problem, I'm putting break in function via debug(fn_ref). Java applet call showDocument with new URL('javascript:my_fn() ') browser generally stops responding. After few seconds I'm able to jump to the next line and another freeze. Breaks are not only problem, typing in firebug is also like in slow motion.

>Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0 actually it's 18.0.1
>Firebug 1.11.1

There is no such problem on Firefox 17.0.1.

Also tested same code on:
>Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.52 Safari/537.17 works fine (as on Firefox 17.0.1)

Also tested with this options switched to false.

javascript.options.ion.content; 
javascript.options.jit_hardening;
javascript.options.methodjit.chrome;
javascript.options.methodjit.content;

Firefox load didn't jump up, but browser GUI didn't respond normaly.
Java 7 update 7 (build 1.7.0_07-b11)
I might sound weird but it's look like java really slows down execution when focus is out of browser window.
My applet opens another java window which interacts with JavaScript (in main bowser window) via described interface. After JavaScript call, functions open window, but changes in this window will not appear till I switch focus to this window. JavaScript thread / Layout thread is being freezed by Java or browser?
Please, could you attach a minimal testcase reproducing the issue or online page to test.
Flags: needinfo?(mylith+mozilla)
This took me a while but here it is. (See url)

Applet should have a button, which open modal window, after click runs test javascript function. Open new window, and change location to google.pl which has no effect until java window is closed.
Flags: needinfo?(mylith+mozilla)
Keywords: testcase
Mozilla/5.0 (Windows NT 6.1; rv:21.0) Gecko/20130121 Firefox/21.0

I see no freezing, but no button is displayed either. Michael, how are you reproducing the freeze with the test case in the URL (steps, guidelines etc)?
Flags: needinfo?(mylith+mozilla)
(In reply to Ioana Budnar [QA] from comment #5)
> Mozilla/5.0 (Windows NT 6.1; rv:21.0) Gecko/20130121 Firefox/21.0
> 
> I see no freezing, but no button is displayed either. Michael, how are you
> reproducing the freeze with the test case in the URL (steps, guidelines etc)?

Do You have java enabled / plugin is running? If You have no button, applet won't run, so You can't reproduce this.

1. Enter url to browser
2. Activate Java SE plugin
3. After loading I have button with "show modal window"
4. Click on it opens java window (there is another button)
5. Click on it calls test() function which opens another browser window.
6. Google.pl should appear in window which has no effect (works fine on FX 17).
Flags: needinfo?(mylith+mozilla)
I'm able to reproducte the issue with the online testcase (you need to accept pop-ups from domain mylith.com).

In fact, in FF18+, the content called (here, it's Google.pl) in the pop-up window doesn't show up if the user doesn't close the previous Java Applet window (with the button to invoke javascript).

NB: I don't know if it's normal or not, but in all versions I tested (since Firefox 8), the Java Applet window blocks the main thread about Firefox UI, tabs can't be switched or menus can't be displayed. The user needs to close this window to interact again with the browser UI.

Regression range:

m-c
good=2012-12-10
bad=2012-12-11
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=725eb8792d27&tochange=4dfe323a663d
Status: UNCONFIRMED → NEW
Ever confirmed: true
FF18/19 builds work normally so I guess it's a patch landed into FF20 then backported into FF18/19.
I'm glad to hear that, anyway since Bug 180048 window.open doesn't allow to use modal option so, for the same reason Java (applet) should not be able to do 'modal' window imho.
This is really nasty, caused many problems in our internal application ( over hundred installations ) after FX update.
(In reply to Loic from comment #7)
> I'm able to reproducte the issue with the online testcase (you need to
> accept pop-ups from domain mylith.com).
> 
> In fact, in FF18+, the content called (here, it's Google.pl) in the pop-up
> window doesn't show up if the user doesn't close the previous Java Applet
> window (with the button to invoke javascript).
> 
> NB: I don't know if it's normal or not, but in all versions I tested (since
> Firefox 8), the Java Applet window blocks the main thread about Firefox UI,
> tabs can't be switched or menus can't be displayed. The user needs to close
> this window to interact again with the browser UI.
> 
> Regression range:
> 
> m-c
> good=2012-12-10
> bad=2012-12-11
> http://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=725eb8792d27&tochange=4dfe323a663d

Load google.pl automatically:
http://hg.mozilla.org/integration/mozilla-inbound/rev/bb0dbeb26f1d
Mozilla/5.0 (Windows NT 5.1; rv:20.0) Gecko/20121209 Firefox/20.0 ID:20121209213450
Load google.pl when popup window gets focus(i.e., click taskbar button of the popup or click the popup):
http://hg.mozilla.org/integration/mozilla-inbound/rev/b30a1fff2d07
Mozilla/5.0 (Windows NT 5.1; rv:20.0) Gecko/20121209 Firefox/20.0 ID:20121209213651
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=bb0dbeb26f1d&tochange=b30a1fff2d07
Triggered by:
	1869f4cbee0b	Robert O'Callahan — Bug 785348. Part 1: Track when we've called into plugin code. While we're in plugin code, never run the refresh driver. r=mats
Blocks: 785348
Severity: normal → critical
Component: Untriaged → Plug-ins
Keywords: hang
Product: Firefox → Core
Hardware: x86_64 → x86
Summary: Browser freezes when java applet calls showDocument() regression? → Browser freezes when java applet calls showDocument()
Priority: -- → P3
This is sort of expected. Calling back into browser code while you're running a modal event loop in Java is dangerous and we're minimizing the amount of exposure we have to that by refusing to repaint windows during that interval.

Maybe we need to relax this. I wonder what the scale of the problem is.
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #11)
> This is sort of expected. Calling back into browser code while you're
> running a modal event loop in Java is dangerous and we're minimizing the
> amount of exposure we have to that by refusing to repaint windows during
> that interval.
> 
> Maybe we need to relax this. I wonder what the scale of the problem is.

Correct me if I'm wrong, but how locking browser thread (try firebug and put break in called function ) by third part plugin is expected? Mozilla is running "Snappy" project to improve Firefox desktop responsiveness how this is helping? 
Since Bug 180048 window.open doesn't allow to use modal option in common cases so, why plugin may do that?
Users are confused and think that browser stops responding.
(In reply to Michael Lipinski from comment #12)
> Correct me if I'm wrong, but how locking browser thread (try firebug and put
> break in called function ) by third part plugin is expected? Mozilla is
> running "Snappy" project to improve Firefox desktop responsiveness how this
> is helping?

When applications do strange and dangerous things, such as running nested event loops in during calls into the plugin, it's more important that we not crash than that we be responsive.
Depends on: 829557
Adding qawanted for checking whether this is fixed by bug 829557.
Keywords: qawanted
(In reply to Loic from comment #7)
> the content called (here, it's Google.pl) in the pop-up
> window doesn't show up if the user doesn't close the previous Java Applet
> window (with the button to invoke javascript)
If this is the main issue in this bug, then it's not fixed by bug 829557 in Nightly 22.0a1 (2013-03-05).
Keywords: qawanted
I thought the issue was that Fx freezes?
Michael, can you clarify which issue this bug is supposed to be about?
Flags: needinfo?(mylith+mozilla)
Indeed, FX still freezes as description says, just tested on 22.0a1 (2013-04-05) built from http://hg.mozilla.org/mozilla-central/rev/015da7030aab

Note, Scoobidiver added depends (Robert O'Callahan confirmed in Comment 14) but fixin Bug 829557 didn't resolved this issue.
Flags: needinfo?(mylith+mozilla)
(In reply to Michael Lipinski from comment #18)
> Indeed, FX still freezes as description says, just tested on 22.0a1

Thanks. I might have missed that above, but is it:
* Fx UI etc. freezing while Java shows a modal window, with all back to normal after the modal window closes (this is expected) or
* Fx completely frozen when/after Java shows a modal window
If we use two or more separate Firefox windows, the one with applet will lock all others. This is kind of blocker. How can I help with this?
If you call showDocument() during processing of a user's input event, it should work. If you call it off a timer or something like that, it won't work. What's on the stack when you call showDocument()?
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #21)
> If you call showDocument() during processing of a user's input event, it
> should work.

Sorry for late reply, I did some tests on current Aurora:
Open browser with 2 tabs, split then into two windows, one goes for applet with modal window, second for other page (this stops loading) and appear immediately after modal window close.

>If you call it off a timer or something like that, it won't
> work. What's on the stack when you call showDocument()?

Stack will be empty in case above.
(In reply to Michael Lipinski from comment #22)
> Sorry for late reply, I did some tests on current Aurora:
> Open browser with 2 tabs, split then into two windows, one goes for applet
> with modal window,

What triggers the applet showing the modal window? User input or something else?
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #23)
> (In reply to Michael Lipinski from comment #22)
> > Sorry for late reply, I did some tests on current Aurora:
> > Open browser with 2 tabs, split then into two windows, one goes for applet
> > with modal window,
> 
> What triggers the applet showing the modal window? User input or something
> else?

It's the same applet from test case ( http://mylith.com/mozilla/832963/applet.html )
And three months later, Firefox 22 is also affected :(.
Depends on: 860490
This may have been fixed by bug 860490, does this still occur on a recent nightly?
Flags: needinfo?(mylith+mozilla)
I confirm this is fixed by bug 860490.
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(mylith+mozilla)
Resolution: --- → FIXED
nightly 2013-08-05
Status: RESOLVED → VERIFIED
Target Milestone: --- → mozilla25
@John Schoenick

Just tested 25.0a1 2013-08-05 build, it's ok. One thing was pretty weird I was unable to turn off popup blocker when modal window was present.
(In reply to Michael Lipinski from comment #29)
> One thing was pretty weird I
> was unable to turn off popup blocker when modal window was present.

Probably because the Java modal dialog blocks the main Firefox window. It's a known behavior.
(In reply to Paul Silaghi [QA] from comment #28)
> nightly 2013-08-05
Verified fixed FF 24b1
Duplicate of this bug: 908565
You need to log in before you can comment on or make changes to this bug.