832963 - Browser freezes when java applet calls showDocument()

Status: VERIFIED FIXED

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

Description

[Michał Lipiński]

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.

Comment 1

[Michał Lipiński]

Java 7 update 7 (build 1.7.0_07-b11)

Comment 2

[Michał Lipiński]

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?

Comment 3

[Loic]

Please, could you attach a minimal testcase reproducing the issue or online page to test.

Comment 4

[Michał Lipiński]

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.

Comment 5

[Ioana (away)]

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)?

Comment 6

[Michał Lipiński]

(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).

Comment 7

[Loic]

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

Comment 8

[Loic]

FF18/19 builds work normally so I guess it's a patch landed into FF20 then backported into FF18/19.

Comment 9

[Michał Lipiński]

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.

Comment 10

[Alice0775 White]

(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

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 12

[Michał Lipiński]

(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.

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(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.

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I expect the patches in bug 829557 to fix this.

Comment 15

[Georg Fritzsche [:gfritzsche]]

Adding qawanted for checking whether this is fixed by bug 829557.

Comment 16

[Paul Silaghi, QA [:pauly]]

(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).

Comment 17

[Georg Fritzsche [:gfritzsche]]

I thought the issue was that Fx freezes?
Michael, can you clarify which issue this bug is supposed to be about?

Comment 18

[Michał Lipiński]

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.

Comment 19

[Georg Fritzsche [:gfritzsche]]

(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

Comment 20

[Michał Lipiński]

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?

Comment 21

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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()?

Comment 22

[Michał Lipiński]

(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.

Comment 23

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(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?

Comment 24

[Michał Lipiński]

(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 )

Comment 25

[Michał Lipiński]

And three months later, Firefox 22 is also affected :(.

Comment 26

[John Schoenick [:johns]]

This may have been fixed by bug 860490, does this still occur on a recent nightly?

Comment 27

[Paul Silaghi, QA [:pauly]]

I confirm this is fixed by bug 860490.

Comment 28

[Paul Silaghi, QA [:pauly]]

nightly 2013-08-05

Comment 29

[Michał Lipiński]

@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.

Comment 30

[Loic]

(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.

Comment 31

[Paul Silaghi, QA [:pauly]]

(In reply to Paul Silaghi [QA] from comment #28)
> nightly 2013-08-05
Verified fixed FF 24b1