850191 - Using alert() in a Java-to-Javascript call (Java Plugin / Liveconnect) freezes firefox / stops repainting the content area

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Frank Dreyer]

Attachment: FirefoxAlertTestcase.zip

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:19.0) Gecko/20100101 Firefox/19.0
Build ID: 20130307023931

Steps to reproduce:

Call the javascript alert() function from a java applet using a LiveConnect:

JSObject window = JSObject.getWindow(this);
window.call("alert", new Object[]{"Hello World"});

I have attached a testsuite which includes 10 testcases with various ways of java-to-javascript calls
- demonstration of just modifying the document without displaying an alert() box
- call alert direct from java
- indirect by calling a javascript function which in turn calls alert
- call from the event dispatch thread and from a worker thread
- using a call to window.SetTimeout as a workaround
- passing objects to javascript


Actual results:

No alert box is displayed, instead firefox almost completely freezes. You can still click on other tabs which correctly changes the window title, but the content area does not repaint anymore even after switching to a different tab.

If you alt+tab to another application and then back to firefox, everything is back to normal and the alert() popup is visible and can be closed using the ok button.

Tested on Firefox 19.0.2 (Windows XP 32 bit) and Firefox 18.0.2 (Windows 7 32 bit) with the same results.

From my testsuite:
#1 and #2: works fine (no alert() used)
#3 and #4: freezes
#5 and #6: works fine (setTimeout workaround)
#7 and #8: firefox freezes, but java application stays responsive (using worker thread instead of event dispatching thread in java)
#9 freezes (example of passing objects to javascript)
#10 works only in firefox, not in IE 8 or chrome 24 (really kludgy workaround to be able to pass objects to javascript and use the setTimeout workaround at the same time)

In Internet Explorer 8 and Google Chrome 24, the testcases #1 - #9 of my testsuite all work fine without any problems. #10 doesn't work in both, but I didn't check how to get it to work there because it shouldn't be nescessary to use such kludgy workarounds in the first place.


Expected results:

Firefox should always behave just as if the alert() call was made directly from javascript code: The alert popup should immediately be shown and be clickable and it should be possible to switch to other tabs.

Comment 1

[Frank Dreyer]

Attachment: FirefoxAlertTestcase_v2.zip

Added 4 more testcases which show that this seems to be a threading issue:
#11: Javascript calls Java which in turn directly calls Javascript -> Works fine
#12: Same as #11 but with a 3 second delay to simulate fetching data from network or disk -> Doesn't show the "freeze until alt+tab" effect but firefox is completely frozen during the 3 seconds delay.
#13 and #14: run the simulated data fetching (#13 without delay, #14 with delay) in a background thread using SwingWorker (i.e. the javascript-to-java call immediately returns) and then when the SwingWorker is finished, do the java-to-javascript call on the event dispatching thread -> Freezes in the same way as #3 and #4, either immediately (#13) or after the 3 seconds delay (#14).

Comment 2

[Loic]

In previous versions of Firefox, all testcases worked (only freezing for #12/#14 during the delay of 3 sec).

Regression range:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=725eb8792d27&tochange=4dfe323a663d

Comment 3

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

Bug 829557 made this work when the Java code is triggered by a user input event.

We don't want to make this work in other situations since displaying an alert() from plugin code is dangerous.

Comment 4

[Frank Dreyer]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #3)
> Bug 829557 made this work when the Java code is triggered by a user input
> event.
> 
> We don't want to make this work in other situations since displaying an
> alert() from plugin code is dangerous.

If I correctly understood the comments of bug 785348, the current behaviour is supposed to prevent a crash which can only happen while a document is being unloaded. Which makes me wonder why the behaviour is also applied while the document is still live - instead of only when the document or the plugin is about to be unloaded.

Comment 5

[Alex Keybl [:akeybl]]

We've released two versions of Firefox with this issue - we'd take a low risk uplift (likely to FF21) but this is basically wontfix at this point.

Comment 7

[johnny_dipin]

Hi 

I have an application that calls a java script confim from a java applet and I see the same behavior as well. When java calls the javascript confirm nothing appears on the screen. But if minimize or maximize the firefox the popup comes up.

Comment 8

[Miguel]

Same behaviour here with another applet that calls javascript to show an alert.  Alert is hidden and shows up when changing to another task and returning to firefox (Alt-Tab).  I'm on Firefox v22

Comment 9

[John Schoenick [:johns]]

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

Comment 10

[Frank Dreyer]

I tested it with nightly version 26.0a1 (2013-08-15) and all of my testcases as well as our real application work fine without any freezing/repaint problems.

The only exception is testcase #12 which completely blocks all input during the 3 seconds Thread.sleep() in the applet. But as soon as the sleep call returns and the alert() is shown, everything works fine there as well.

Comment 11

[John Schoenick [:johns]]

(In reply to Frank Dreyer from comment #10)
> The only exception is testcase #12 which completely blocks all input during
> the 3 seconds Thread.sleep() in the applet. But as soon as the sleep call
> returns and the alert() is shown, everything works fine there as well.

Applets blocking input while capturing the event loop is a separate issue*, so I'm going to call this fixed. Thanks for filing this and helping test!

* Though I can't find the bug # -- feel free to file a new bug about this if it's an issue.