Closed Bug 860052 Opened 11 years ago Closed 8 years ago

Java plugins w/OpenJDK+wmode=transparent get caught in nested event loop, browser ceases repainting w/ "ASSERTION: Refresh driver should not run during plugin call"

Categories

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

21 Branch
x86_64
Linux
defect

Tracking

(firefox20 unaffected, firefox21- wontfix, firefox22- affected, firefox23- affected)

RESOLVED WORKSFORME
Tracking Status
firefox20 --- unaffected
firefox21 - wontfix
firefox22 - affected
firefox23 - affected

People

(Reporter: johns, Unassigned)

References

()

Details

(Keywords: regression, reproducible)

Attachments

(1 file)

This is very similar to bug 850191, but occurs with any java applet whatsoever on my configuration.

On my linux 64 box with java 7 OpenJDK + IcedTea, I am unable to spawn java plugins on a fresh profile without the browser UI locking up, while the console is spammed with
> ###!!! ASSERTION: Refresh driver should not run during plugin call!

Breaking a few times in a debugger shows that we are trapped in a nested event loop (!!) inside nsObjectLoadingContent::InstantiatePluginInstance.
It's really quite normal (if sucky) for Java to spin nested event loops. I really don't like these assertions.
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #1)
> It's really quite normal (if sucky) for Java to spin nested event loops. I
> really don't like these assertions.

So should we remove them in general or special case for Java here?
Priority: -- → P2
Is this blocking your workflow, or do we think that this is a regression from bug 785348? That bug has been fixed since FF18 (see status flags), so it's not clear why Firefox 20 is marked as unaffected here.
This doesn't reproduce on 20 on my machine. It's not clear how widespread this is, but if we entirely broke, say, Java 7 on linux, that's bad.
So this happens on windows too, but we seem to "escape" from the nested event loop -- sometimes. Using http://www.java.com/en/download/testjava.jsp we get caught in this event loop for a brief period, janking the UI, but using the test applet here:

http://johns.mv.mozilla.com:7000/bug856969/test.htm

We get caught in the nested event loop indefinitely.
If i understand you right we don't know what exactly triggered this, so a regression-window would help.
(In reply to Georg Fritzsche [:gfritzsche] from comment #6)
> If i understand you right we don't know what exactly triggered this, so a
> regression-window would help.

Taking a look at this now.
QA Contact: anthony.s.hughes
(In reply to John Schoenick [:johns] from comment #5)
> http://www.java.com/en/download/testjava.jsp

The effect of trying to scroll while loading this page is exactly the same to me going back to Firefox 18 so far.

> http://johns.mv.mozilla.com:7000/bug856969/test.htm

Can you put this somewhere I can access it? It doesn't load for me.
Flags: needinfo?(jschoenick)
A simple example that loads a empty applet with wmode=transparent:
  http://people.mozilla.org/~jschoenick/bug860052.htm

Doing some more testing, this only seems to affect OpenJDK on linux, not Oracle JRE.

I was able to reproduce this occasionally in windows with the test case in bug 856969, but that test fails in some way on all branches there, so probably isn't relevant.
Flags: needinfo?(jschoenick)
Summary: Java plugins get caught in nested event loop, browser ceases repainting w/ "ASSERTION: Refresh driver should not run during plugin call" → Java plugins w/OpenJDK+wmode=transparent get caught in nested event loop, browser ceases repainting w/ "ASSERTION: Refresh driver should not run during plugin call"
Priority: P2 → P3
Tested on Ubuntu 12.04 64bit with OpenJDK 7 and IcedTea. This is the regression range I got:

Last good nightly: 2013-03-18
First bad nightly: 2013-03-19

http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2013-03-18&enddate=2013-03-19
QA Contact: anthony.s.hughes → ioana.budnar
Can this reproduce on FF21? If the regression range is correct then this landed on FF22 on central.  If it's affecting 21 then we're looking for something that got uplifted to aurora during 22's time on nightly.
(In reply to lsblakk@mozilla.com from comment #11)
> Can this reproduce on FF21? If the regression range is correct then this
> landed on FF22 on central.  If it's affecting 21 then we're looking for
> something that got uplifted to aurora during 22's time on nightly.

John Schoenick originally reported this as affecting Firefox 21, 22, and 23. 

Ioana, can you please confirm which branches are affected by this bug?
Firefox 21, 22 and 23 are affected by this bug, as John specified.
Keywords: qawanted
(In reply to Ioana Budnar, QA [:ioana] from comment #13)
> Firefox 21, 22 and 23 are affected by this bug, as John specified.

(In reply to Ioana Budnar, QA [:ioana] from comment #10)
> Tested on Ubuntu 12.04 64bit with OpenJDK 7 and IcedTea. This is the
> regression range I got:
> 
> Last good nightly: 2013-03-18
> First bad nightly: 2013-03-19
> 
> http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2013-03-
> 18&enddate=2013-03-19

Ioana, can you please help us find the regression window on aurora by any chance ?
:benjamin, these bugs were the Firefox 21 uplifts from the regression range in comment# 10, 837486,844331,851436,851489..Nothing obvious to the plug-in code from my first look.

Can you please suggest next steps here and help find an assignee given this is reproducible ?
When trying to find a regression range on Firefox 21 Aurora, I get the following pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2013-04-01&enddate=2013-04-02

Considering that, I re-tested manually on Firefox 21 and noticed that although I could reproduce the issue on it, it is quite intermittent. It's not intermittent on Firefox 22 for me. Could these be two different bugs?
Flags: needinfo?(benjamin)
I don't think this bug is important enough to track.
Flags: needinfo?(benjamin)
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #17)
> I don't think this bug is important enough to track.

Why do you feel that way? KaiRo believes that many distros install OpenJDK by default due to licensing. We'd be dropping Linux Java support for many of our users.
Flags: needinfo?(benjamin)
As I understand the bug, it only occurs

* On Linux with OpenJDK not Oracle JDK
* With windowless plugins
* Is a broken plugin behavior anyway.

The stacks from the Firefox process are not especially interesting here; what might be interesting is the stack from the plugin-container process. Presumably we can have a full stack as long you have the debuginfo for the openjdk plugin.

wmode="transparent" java is very unusual because AFAIK Java doesn't support windowless mode on Windows at all.
Flags: needinfo?(benjamin)
Sent email to module owners/peers to make sure this decision is final.
My results are a bit different than John's and Ioana's.

In summary, I find that in the latest m-c 23 nightly, there are no problems (for me) in opening and displaying applets whose wmode is set to "transparent", using OpenJDK.

However, I can cause a hang with any sample that uses an incorrect URI for the applet. John's sample has no URI specified, and I have tried other tests with various bad URIs. In these cases, renavigating the page - back and then forward - hangs the browser badly.

1. Use this URL: http://people.mozilla.org/~jschoenick/bug860052.htm
2. Browser back button
3. Browser forward button

So, I guess I'd like to see if John wouldn't mind using an example that has a valid applet to see if he can still cause a crash or other badness.


Configs I used:

Ubuntu 13.0.4
java version "1.7.0_21"
OpenJDK Runtime Environment (IcedTea 2.3.9) (7u21-2.3.9-1ubuntu1)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)

Ubuntu 12.0.4
java version "1.6.0_27"
OpenJDK Runtime Environment (IcedTea6 1.12.3) (6b27-1.12.3-0ubuntu1~12.04.1)
OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)
(In reply to Matt Wobensmith from comment #21)
> In summary, I find that in the latest m-c 23 nightly, there are no problems
> (for me) in opening and displaying applets whose wmode is set to
> "transparent", using OpenJDK.

Is this true in Firefox 21 as well?

> So, I guess I'd like to see if John wouldn't mind using an example that has
> a valid applet to see if he can still cause a crash or other badness.

ni? on John.
Flags: needinfo?(mwobensmith)
Flags: needinfo?(jschoenick)
Interesting. With the test above:

FF18 - no hang
FF20 - hang
FF21 - no hang

And of course, with the latest m-c 23 we get a hang.

I dunno what this means.
Flags: needinfo?(mwobensmith)
Based upon the testing completed, we're going to call this wontfix for FF21 since we're not able to reproduce reliably on other systems. If this had been a more prominent issue, we would have continued tracking.
So similar to c21, I can get a working plugin with wmode=transparent in some cases. I can also sometimes avoid the test case breaking if I spawn a working plugin in one tab prior to launching the test case.

So as far as we know, this bug is basically:
1 We no longer allow repainting inside nested event loops
2 Java spins nested event loops as a normal mode of operation
3 Only in some odd situations does this occur for indefinite amounts of time

I suspect [1] means that [2] will cause what seems like jank when it occurs, but if you're loading java that's probably going to happen anyway. It's possible that we'll find out some common applet or configuration hits [3], but since a good deal of uses of java are obscure or on corporate intranets at this point, it's difficult to predict whether this will be a problem.
Flags: needinfo?(jschoenick)
Depends on: 860490
See Also: → 1023187
No longer relevant because we've forced all plugins out of process.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: