323142 - Selecting from drop down in Java applet no longer populates field

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Ian Neal]

We use a web-based app created by Northgate and the Java applets in it, which has been developed using Oracle Developer 6i, have various fields that can be populated by selecting from a list of values within a drop down. This was working fine in BuildID 2005091705 but does not in BuildID 2005091805. The plugin it uses is Oracle's Jinitiator v 1.3.1.13

CCing only person who did a checkin for plugins in the regression window

Comment 1

[Ian Neal]

Just to confirm this affects the latest build (BuildID 20060111) on the trunk for both Firefox and suite but does not seem to affect 1.8.0 branch

Comment 2

[Ian Neal]

Bug 306209 is the possible cause

Comment 3

[Ian Neal]

Tested by backing out bug 306209 locally and it does fix the issue.

Comment 4

[Ian Neal]

Attachment: Backout fix to bug 306209 patch v0.1

I'm proposing we back out the patch to bug 306209 to fix this bug and reopen that bug.

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Could you attach a testcase?
I don't think that this issue is our bug.

Comment 6

[Ian Neal]

Unfortunately I do not program in Java so I cannot attach a testcase. If it is not bug 306209 then why does backing out that patch fix the problem?

Comment 7

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to comment #6)
> Unfortunately I do not program in Java so I cannot attach a testcase. 

What's? You said we have a problem on Java appletes. We need to testcase if we really have a problem. But you cannot attach the simple testcase, we cannot confirm the problem.

> If it is not bug 306209 then why does backing out that patch fix the problem?

It may be Java applete or JavaVM's trouble, right?

Comment 8

[Ian Neal]

(In reply to comment #7)
> (In reply to comment #6)
> > Unfortunately I do not program in Java so I cannot attach a testcase. 
> 
> What's? You said we have a problem on Java appletes. We need to testcase if we
> really have a problem. But you cannot attach the simple testcase, we cannot
> confirm the problem.

I suspect any testcase will involve populating the drop down from a database query. The application makes use of 13 JAR files varying in size from 10K to almost 4M.
> 
> > If it is not bug 306209 then why does backing out that patch fix the problem?
> 
> It may be Java applete or JavaVM's trouble, right?
> 
As I said earlier in the bug, it works fine when the patch is backed out. It works fine on the 1.8 branch where the patch was not checked in. Additionally it works fine on 1.7 branch and in IE. All this using the same version of JRE and applets.

Comment 9

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

We need simple test case and the applete's code.
We should not back out the patch before confirming the problem is our bug.

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to comment #8)
> As I said earlier in the bug, it works fine when the patch is backed out. It
> works fine on the 1.8 branch where the patch was not checked in. Additionally
> it works fine on 1.7 branch and in IE. All this using the same version of JRE
> and applets.

The patch raise only DOM event. We did *not* change the actual focus mechanism.
I think that the Java applete or JavaVM may not be handling the focus event correctly.

Comment 11

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Ere:

Why you grant to the patch? We don't confirm the problem yet.

Comment 12

[Ere Maijala (slow)]

Ian said backing out the patch fixed the problem. That's enough to warrant a re-examination. It's fruitless to blame the applet or VM because a change in our widget code clearly caused the problem. And as Roc noted, the patch for bug 306209 was scary.

Comment 13

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I don't think so. Because DOM focus event should be fired always. So, it should not be suppressed by plug-ins. Do you have better idea for this issue? And if the patch is backed-out, we may not be able to use IME on SWF.(I'm confirming this.) This is serious problem for CJK users.

Comment 14

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I confirmed the IME problem is not occured by this backing-out. We are the worst problem is avoidable.

But I think we should contact to Oracle before backing-out. Can somebody contact to Oracle? If nobody can contact to Oracle, Mozilla Japan or Mozilla Corporation will contact to Oracle.

Comment 15

[Ian Neal]

I could try logging a support call with them via Metalink but, because this is not in a released version of Firefox/SeaMonkey, I doubt it would go very far.

Comment 16

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Gecko1.9 will be released in last of this year. So, we have much time. We should fix this bug correctly. If this is our bug, we should back-out the patch. But if this is Oracle's bug, Oracle should fix the bug before Fx3 release.

Comment 17

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

FYI: As the bug which was alike, we have bug 311622. That problem is regression by bug 310174. But the problem is occured by Flash Player's bug. Therefore, we contacted to Macromedia, and they fix the problem on next release. I think that this problem is same as bug 311622.

Comment 18

[Ian Neal]

Well if you know the right people to speak to at Oracle and/or Northgate that will test and fix, if it is a JRE problem, prior to an official release of a mozilla product containing Gecko 1.9 then you must have some very good contacts as I always hit a brick wall whenever I try anything like that.

Comment 19

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Oops. The problem is ocuured on Northgate's product? What's the name of application?

Comment 20

[Ian Neal]

Housing v5.7.1 but it was created using Oracle's development tools. I will check what versions of forms/etc it is later.

Comment 21

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Would you tell me the URI of Northgate web site and the product page?
I cannot find the site...

Comment 22

[Ian Neal]

Should be something like http://www.northgate-is.com but housing will have it's own microsite just need to track that down.
It runs off 9iAS and is developed on top of Developer 6i patch level 16 and Oracle DB 9.2.0.4.

Comment 23

[Ian Neal]

Okay site for Housing Solution is http://www.northgate-ispublicservices.com/index.php
Click on "Social Housing" under the "Our Solutions" list

Comment 24

[Masatoshi Kimura [:emk]]

Attachment: true fix

JInitator creates its own window as a child of Mozilla Plaug-in window.
When JInitator window is clicked, Mozilla wouldn't focus to the JInitator window but Mozilla Plug-in window. Then JInitator window will be focused immediately after Mozilla Plug-in window by Operating System. This focus dance seems to make JInitator unhappy.
This patch will fix this bug and don't regress bug 306209. This will also fix bug 300786.

Comment 25

[Ere Maijala (slow)]

Comment on attachment 210027 [details] [diff] [review]
true fix

Reviewing blindfolded without a testcase, but the patch looks sensible. I'd just change the beginning of the comment to:

+      // If a child window of this plug-in is already focused,
+      // don't focus the parent to avoid focus dance.

Comment 26

[Masatoshi Kimura [:emk]]

Attachment: with the comment changed

> Reviewing blindfolded without a testcase,
Oops, I forgot to mention how to test this patch.
1. Go to http://www.commandsystems.com/e-s-center.html
2. Download and install jinit13117.exe from "click here" anchor.
3. Copy NPJinit13117.dll to the plugins folder if required.
4. Restart Firefox.
5. Click the door on http://www.commandsystems.com/e-s-center.html
6. Click "Walk-in".
7. Click "Login Now!".
8. Click "Search Solution Database / Open a New Problem".
9. Select a value from dropdown.
Works fine once the patch is applied.

Comment 27

[Masatoshi Kimura [:emk]]

Ian:
Does this patch solve your problem?

Comment 28

[Ian Neal]

I'll have to see if I can persuade someone to create another build for me with this patch applied so I can test as I did for testing the backout.

Comment 29

[Masatoshi Kimura [:emk]]

Here is a patched build.
http://www.oersted.co.jp/~emk/2006/01/fb-323142test.zip
SHA1 hash: fe7bd3c0fa5e78720fb299a4c9fb3c95429e2d38

Comment 30

[Ian Neal]

(In reply to comment #29)
> Here is a patched build.
> http://www.oersted.co.jp/~emk/2006/01/fb-323142test.zip
> SHA1 hash: fe7bd3c0fa5e78720fb299a4c9fb3c95429e2d38
> 

Tested that build and it does seem to fix the problem, thanks :-)

Comment 31

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

checked-in. Thank you, Kimura-san.