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)
Tracking
(firefox20 unaffected, firefox21- wontfix, firefox22- affected, firefox23- affected)
RESOLVED
WORKSFORME
People
(Reporter: johns, Unassigned)
References
()
Details
(Keywords: regression, reproducible)
Attachments
(1 file)
7.38 KB,
text/plain
|
Details |
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.
Reporter | ||
Updated•11 years ago
|
status-firefox20:
--- → unaffected
status-firefox21:
--- → affected
status-firefox22:
--- → affected
status-firefox23:
--- → affected
tracking-firefox21:
--- → ?
tracking-firefox22:
--- → ?
tracking-firefox23:
--- → ?
Comment 1•11 years ago
|
||
It's really quite normal (if sucky) for Java to spin nested event loops. I really don't like these assertions.
Comment 2•11 years ago
|
||
(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?
Updated•11 years ago
|
Priority: -- → P2
Comment 3•11 years ago
|
||
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.
Reporter | ||
Comment 4•11 years ago
|
||
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.
Reporter | ||
Comment 5•11 years ago
|
||
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.
Comment 6•11 years ago
|
||
If i understand you right we don't know what exactly triggered this, so a regression-window would help.
Keywords: qawanted,
regressionwindow-wanted
(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.
Updated•11 years ago
|
Flags: needinfo?(jschoenick)
Reporter | ||
Comment 9•11 years ago
|
||
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"
Updated•11 years ago
|
Priority: P2 → P3
Comment 10•11 years ago
|
||
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
Keywords: qawanted,
regressionwindow-wanted
Updated•11 years ago
|
QA Contact: anthony.s.hughes → ioana.budnar
Comment 11•11 years ago
|
||
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.
Comment 12•11 years ago
|
||
(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?
Comment 13•11 years ago
|
||
Firefox 21, 22 and 23 are affected by this bug, as John specified.
Keywords: qawanted
Comment 14•11 years ago
|
||
(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 ?
Comment 15•11 years ago
|
||
: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 ?
Comment 16•11 years ago
|
||
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?
Updated•11 years ago
|
Flags: needinfo?(benjamin)
Comment 17•11 years ago
|
||
I don't think this bug is important enough to track.
Flags: needinfo?(benjamin)
Comment 18•11 years ago
|
||
(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)
Comment 19•11 years ago
|
||
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)
Comment 20•11 years ago
|
||
Sent email to module owners/peers to make sure this decision is final.
Comment 21•11 years ago
|
||
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)
Comment 22•11 years ago
|
||
(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)
Comment 23•11 years ago
|
||
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)
Comment 24•11 years ago
|
||
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.
Reporter | ||
Comment 25•11 years ago
|
||
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)
Comment 26•8 years ago
|
||
No longer relevant because we've forced all plugins out of process.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•