STR: 1) Run a Java applet that creates, or can create, a stand-alone Java window, e.g. http://www.aispace.org/deduction/version4.2.1/launcher.html or http://www.prophet.net/analyze/javacharts.jsp?symbol=AAPL 2) Attempt to do something that relies on mouse tracking 3) Fail For specific examples: in the AIspace applet, pull down the menus in the applet window and see that there are no highlights. In the ProphetCharts example, the breakage is much more severe, especially in full versions of ProphetCharts with more features: 1) Before detaching the chat, mouse over the chart and observe that not only does the red line follow the mouse, but the values under the stock name update as the cursor changes dates. 2) Detach the chart 3) Repeat step 1 and notice that the red line does not move nor do the values update as the cursor moves. (In more advanced versions of ProphetCharts that have in-window menubars, it's impossible to open submenus, for instance, and drawing lines, etc. on the chart is difficult at best.) This regression makes stand-alone applets between difficult and impossible to use, and in the Prophet case, the work-around of not detaching the applet means you're stuck with a very limited applet size, which makes it just as difficult to use). I'm on 10.5.7/Intel with all the latest updates, and I see this in today's 1.9.0 nightlies for both Camino and Firefox; I assume it also exists in Firefox on 1.9.1 but I haven't had a chance to check there yet.
Obvious question: Does the problem also occur with earlier JEP versions?
No; 0.9.6 is fine. I haven't checked 0.9.7 because I understand it was very buggy.
(In reply to comment #0) > I'm on 10.5.7/Intel with all the latest updates, and I see this in today's > 1.9.0 nightlies for both Camino and Firefox; I assume it also exists in Firefox > on 1.9.1 but I haven't had a chance to check there yet. Let's get QA on this now and see if it's worth blocking 1.9.1 on (assuming it exists there).
(In reply to comment #2) > No; 0.9.6 is fine. I haven't checked 0.9.7 because I understand it was very > buggy. 0.9.6.4, sorry; the version that was just replaced by 0.9.7.1 on Gecko 1.9.0.
Using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090528 Shiretoko/3.5pre, I do see the highlights on http://www.aispace.org/deduction/version4.2.1/launcher.html. Will check the other site next.
(In reply to comment #5) > Using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) > Gecko/20090528 Shiretoko/3.5pre, I do see the highlights on > http://www.aispace.org/deduction/version4.2.1/launcher.html. Marcia, do you see the highlight on items within the menus, or just on menu titles? The menu titles will show the highlight, but items within the menus don't. I just grabbed today's Fx3.5pre nightly and both of the problems I saw in comment 0 also appear in it (Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090528 Shiretoko/3.5pre) for me.
Java Embedding Plugin 0.9.6.5 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090528 Shiretoko/3.5pre I don't see highlighting of menu items as I move the mouse cursor, in the first example. The second example fails to load for me.
Actually, I am using 0.9.7.1, but my browser was lying to me. A fresh profile shows 0.9.7.1. Still, there isn't any highlighting of the menu items.
> http://www.aispace.org/deduction/version4.2.1/launcher.html With this site I can see the bug (with JEP 0.9.7 and 0.9.7.1), on both the 1.9.0 and 1.9.1 branches. I see it whether or not I trust the signed applet. I don't see the bug with JEP 0.9.6.5. Even with JEP 0.9.7.1 and 0.9.7, I don't see this bug with FF 188.8.131.52 or with 1.8-branch Seamonkey. 1) Visit the site (and choose to trust the applet or not). 2) Click on the Start Applet button. 3) In the window that opens in step 2: a) Click on a menu item at the top of the window, then let go of the mouse button. b) Move the mouse around. Different items in the current menu should be highlighted as the mouse moves over them, and different menus should be opened. This happens with JEP 0.9.6.5 (and in 1.8-branch Firefox and Seamonkey). It doesn't happen (in Cocoa-based browsers) with JEP 0.9.7 and 0.9.7.1. > http://www.prophet.net/analyze/javacharts.jsp?symbol=AAPL Please tell us how to make this site's applet open in a separate window.
I'd also like to see other testcases -- to find out if it's really the case that this bug happens in all applet-opened windows, and to get an idea of how serious it really is.
Forgot to mention that I see the bug on both OS X 10.4.11 and 10.5.7.
Smokey: I was just over with juanb testing this and despite the fact we are testing on almost identical machines, we are getting different results: Using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090528 Shiretoko/3.5pre with JEP 0.9.7.1 I see the menu highlights and the menu titles highlighted. Juan launched with a fresh profile and I see what both of you are seeing but I cannot reproduce on my machine.
>> http://www.prophet.net/analyze/javacharts.jsp?symbol=AAPL > > Please tell us how to make this site's applet open in a separate > window. Now I see that the in-page applet has a "Detach" button, which (when you press it) launches the applet in new Java-created window. I can reproduce the bug in this window (in Cocoa-based browsers with JEP 0.9.7.1 and 0.9.7). I'd still like to see more examples, though.
(In reply to comment #10) > I'd also like to see other testcases -- to find out if it's really the case > that this bug happens in all applet-opened windows, and to get an idea of how > serious it really is. I don't have a repository of Java applets to test against; the only other applet I know of offhand that opens its own window is http://wwwis.win.tue.nl/~debra/2R350/html/menus.html (from bug 382818), but that applet doesn't appear to do anything in its own window (it exists solely to demo adding menus to the native Mac OS X menubar). Here are my summary results: Firefox 3.1b3 (ships with JEP 0.9.6.5) works. Firefox 3.5b4 (ships with JEP 0.9.7) fails. Firefox 3.5pre nightly (ships with JEP 0.9.7.1) fails. Firefox 3.5pre nightly with JEP 0.9.6.5 works, although applets don't always load on the first try and tracking is not smooth (even in in-page applets). Firefox 3.5pre nightly with JEP 0.9.7 fails (plus applets don't always load on first try). Firefox 3.5pre nightly with JEP 0.9.7.1 fails. (And for Gecko 1.9.0:) Camino 2.0b3pre nightly with JEP 0.9.6.5 works. Camino 2.0b3pre nightly with JEP 0.9.7 fails. Camino 2.0b3pre nightly with JEP 0.9.7.1 fails. Firefox 3.0.12pre nightly with JEP 0.9.7.1 fails.
> I don't have a repository of Java applets to test against; I do (built up over a very long time -- see bug 371084 comment #3). But it doesn't contain any applets that create their own windows and then do things in them in reaction to mouse movement (as opposed to clicking or dragging -- both of which seem to work fine). Or rather my "repository" *does* contain one ... but it's reaction to mouse movement is so subtle that I missed this bug in my testing for both JEP 0.9.7 and JEP 0.9.7.1. This example is at http://www.map24.com: 1) Wait for the applet to finish loading (this can take as long as 30 seconds). 2) Once it's finished loading, click somewhere in it (to avoid a different bug (in the applet) that also effects Safari). 3) Click on the "two windows" symbol (at the top of the applet, third from the right). The applet will open in a separate, Java-generated window (i.e. not a browser window). 4) With JEP 0.9.6.5, you can see various things happen as you move the mouse around over the window (menu items change color, and sometimes you see tooltips). You don't see these with JEP 0.9.7 or 0.9.7.1 (in Cocoa-based browsers). So it does look like this bug happens in any Java-created window.
I don't know how long it will take to fix this bug -- maybe a day, maybe a week. And I'm currently very busy with Cocoa widgets stuff. So I'd prefer putting off fixing this bug until JEP 0.9.7.1 gets into the hands of fairly large numbers of users ... to see if any more bugs get shaken out that I'll have to fix.
(In reply to comment #16) > So I'd prefer putting off fixing this bug until JEP 0.9.7.1 gets into > the hands of fairly large numbers of users ... to see if any more bugs > get shaken out that I'll have to fix. We would...prefer that we not put known bugs into the hands of large numbers of users. Wouldn't it be better to fix the ones you know about now, and therefore not have to worry about them if/when you have others reported? (Is that Cocoa widgets stuff for Mozilla? If so, I would prioritize this higher than most other trunk-targeted cocoa work, I think, since we're at risk of shipping this regression not only in 3.5 soon, but to the rest of our users in 3.0.12 shortly after!)
(In reply to comment #17) Your call, I guess. I don't feel strongly either way. But, though I give the JEP as much testing as I can, I'm just one person. And (as far as I know) there's no-one else besides me who does organized testing of the JEP. So there's some danger that I'll have to release a string of updates, each one containing relatively minor changes, as new bugs are found. On the plus side, the JEP is very stable, and (in recent versions) has had very few bugs, most of which have been quite minor. So the chance of there being further bugs is small. But, though I hate to increase the already terrible burden on the QA people, I think what's happened here argues for adding a bunch of my Java tests to Litmus. I've posted a list of the sites I test with (slightly out of date) to bug 371084 comment #3. Over time I can work with the QA people to add my tests to Litmus (I figure this will take at least a few weeks, especially as I can't work on it full time). In the meantime, I'll plan on stopping my Mozilla Corp work until I've fixed this bug. Like I said above, I don't know how long this will take -- possibly as long as a week.
Steven, is there anything from the QA side which could need my attention? Do you still need examples?
(In reply to comment #19) I'll need to work with you QA people to get my tests into Litmus. I don't have time for that now, but I want to find time within the next six months or so. Making usable/practical lists of Java applets to test with is difficult. There aren't that many "in release" that are accessible to everyone, so you tend to come across them by accident. But it's even more difficult to keep each item in your list relevant to the task at hand (testing the JEP, or some other applet-hosting environment). You want each one to either be very popular (so that breaking it will cause trouble for lots of users) or to be very good at testing some particular set of features (so that it can stand in for other applets of its class). If you just keep adding items to your list at random, it will soon get too long to be of any practical use in testing. That said, I'd be very interested in any Java applets you've found that aren't already in my list (see bug 371084), and which somehow push the envelope (by doing unusually interesting or difficult things). I'd also like to know about any particularly popular applets that I might have missed. Of course I'd also like to know about applets that cause trouble with the JEP (and not also with Safari) ... and soon :-)
> Do you still need examples? Of this bug? No. The three I have now are plenty.
Nominating for in litmus based on Steven's Comment 20. That way we won't forget about adding some tests.
So do we need to back out JEP 0.9.7 from the 1.9.0 branch? We took that to fix a crash that people aren't experiencing yet (10.6 hasn't shipped), whereas people will experience this regression and complain. We don't need to give people reasons not to take security updates.
I frankly think this isn't a major bug, and is much less serious than not working at all on SnowLeopard (which is supposed to be coming out "this summer"). This bug has existed since JEP 0.9.7 was landed on the 1.9.1 branch (2009-04-17), but was only reported quite recently. I suspect the reason for this is that not many people rely on running applets in separate (Java-generated) windows. In any case, I've got this bug fixed in my working version of the JEP (what will become JEP 0.9.7.2), and am now going through my battery of tests.
personally, I use things like MindTerm SSH, which I believe counts as a Java created window (i use the pop out feature). That said, I'd prefer to have Firefox not crash on the computers I visit, I'd be willing to eat a minor inconvenience and get that fixed in an update.
This does turn out to have been a bug in JEP 0.9.7/0.9.7.1. I just released a new JEP (0.9.7.2) that fixes it. See bug 496187.
This was fixed on 184.108.40.206 by the landing of bug 496187.
I tried the first example. This seems to be just what I've experiencing when playing full screen flash videos since Firefox 3.0 (see https://bugzilla.mozilla.org/show_bug.cgi?id=435868). Could there be a connection between these issues?
> Could there be a connection between these issues? No. This was a bug in the Java Embedding Plugin, which has nothing to do with full screen Flash videos.
I'm using Firefox 3.0.11 with Java Embedding Plugin 0.9.6.4 on OS X 10.5.7 and cannot reproduce this bug. Juan, can you try reproducing this in 3.0.11 again and with the 3.0.12 build 1?
Al: This needs to be reproduced using JEP version 0.9.7 or 0.9.7.1. You can download old versions here: http://sourceforge.net/projects/javaplugin/files/
Fixed this in 220.127.116.11, so we should fix it in 18.104.22.168.
Fixed (on 1.9.0 and 1.9.1 branches) by patch for bug 496187.
Verified fixed with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:22.214.171.124) Gecko/20090715 Firefox/3.5.1, using STR from comment #0.
Thanks for your help verifying this, Steven.
> Thanks for your help verifying this, Steven. You're welcome. Verified fixed with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:126.96.36.199pre) Gecko/2009062504 GranParadiso/3.0.12pre, using STR from comment #0.