495278 - JEP 0.9.7/0.9.7.1 break mouse-move tracking in Java-created windows

Status: VERIFIED FIXED

(Plugins Graveyard :: Java (Java Embedding Plugin), defect)

Description

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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.

Comment 1

[Steven Michaud [:smichaud] (Retired)]

Obvious question:

Does the problem also occur with earlier JEP versions?

Comment 2

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

No; 0.9.6 is fine.  I haven't checked 0.9.7 because I understand it was very buggy.

Comment 3

[Samuel Sidler (old account; do not CC)]

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

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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

Comment 5

[Marcia Knous [:marcia]]

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.

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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

Comment 7

[juan becerra [:juanb]]

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.

Comment 8

[juan becerra [:juanb]]

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.

Comment 9

[Steven Michaud [:smichaud] (Retired)]

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

Comment 10

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 11

[Steven Michaud [:smichaud] (Retired)]

Forgot to mention that I see the bug on both OS X 10.4.11 and 10.5.7.

Comment 12

[Marcia Knous [:marcia]]

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.

Comment 13

[Steven Michaud [:smichaud] (Retired)]

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

Comment 14

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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

Comment 15

[Steven Michaud [:smichaud] (Retired)]

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

Comment 16

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 17

[Mike Shaver (:shaver emeritus)]

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

Comment 18

[Steven Michaud [:smichaud] (Retired)]

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

Comment 19

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Steven, is there anything from the QA side which could need my attention? Do you still need examples?

Comment 20

[Steven Michaud [:smichaud] (Retired)]

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

Comment 21

[Steven Michaud [:smichaud] (Retired)]

> Do you still need examples?

Of this bug?  No.  The three I have now are plenty.

Comment 22

[Marcia Knous [:marcia]]

Nominating for in litmus based on Steven's Comment 20. That way we won't forget about adding some tests.

Comment 23

[Daniel Veditz [:dveditz]]

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.

Comment 24

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 25

[timeless]

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.

Comment 26

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 27

[Samuel Sidler (old account; do not CC)]

This was fixed on 1.9.0.12 by the landing of bug 496187.

Comment 29

[orion.mozilla]

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?

Comment 30

[Steven Michaud [:smichaud] (Retired)]

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

Comment 31

[Al Billings [:abillings - ex-MoCo]]

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?

Comment 32

[Samuel Sidler (old account; do not CC)]

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/

Comment 33

[Samuel Sidler (old account; do not CC)]

Fixed this in 1.9.0.12, so we should fix it in 1.9.1.1.

Comment 34

[Steven Michaud [:smichaud] (Retired)]

Fixed (on 1.9.0 and 1.9.1 branches) by patch for bug 496187.

Comment 35

[Steven Michaud [:smichaud] (Retired)]

Verified fixed with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.1, using STR from comment #0.

Comment 36

[juan becerra [:juanb]]

Thanks for your help verifying this, Steven.

Comment 37

[Steven Michaud [:smichaud] (Retired)]

> 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:1.9.0.12pre) Gecko/2009062504 GranParadiso/3.0.12pre, using STR from comment #0.