Closed Bug 323142 Opened 19 years ago Closed 19 years ago

Selecting from drop down in Java applet no longer populates field

Categories

(Core Graveyard :: Plug-ins, defect)

x86
Windows XP
defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: iannbugzilla, Assigned: emk)

References

Details

(Keywords: ecommerce, regression, Whiteboard: needs simple testcase)

Attachments

(1 file, 2 obsolete files)

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
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
Bug 306209 is the possible cause
Tested by backing out bug 306209 locally and it does fix the issue.
Depends on: 306209
Attached patch Backout fix to bug 306209 patch v0.1 (obsolete) (deleted) — Splinter Review
I'm proposing we back out the patch to bug 306209 to fix this bug and reopen that bug.
Attachment #209566 - Flags: superreview?(roc)
Attachment #209566 - Flags: review?(emaijala)
Could you attach a testcase? I don't think that this issue is our bug.
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?
(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?
(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.
We need simple test case and the applete's code. We should not back out the patch before confirming the problem is our bug.
Whiteboard: needs simple testcase
Attachment #209566 - Flags: superreview?(roc)
Attachment #209566 - Flags: review?(emaijala)
Attachment #209566 - Flags: review+
(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.
Ere: Why you grant to the patch? We don't confirm the problem yet.
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.
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.
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.
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.
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.
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.
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.
Oops. The problem is ocuured on Northgate's product? What's the name of application?
Housing v5.7.1 but it was created using Oracle's development tools. I will check what versions of forms/etc it is later.
Would you tell me the URI of Northgate web site and the product page? I cannot find the site...
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.
Okay site for Housing Solution is http://www.northgate-ispublicservices.com/index.php Click on "Social Housing" under the "Our Solutions" list
Attached patch true fix (obsolete) (deleted) — Splinter Review
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.
Assignee: nobody → VYV03354
Attachment #209566 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #210027 - Flags: review?(emaijala)
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.
Attachment #210027 - Flags: review?(emaijala) → review+
Attached patch with the comment changed (deleted) — Splinter Review
> 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.
Attachment #210027 - Attachment is obsolete: true
Attachment #210028 - Flags: superreview?(roc)
Attachment #210028 - Flags: review+
Ian: Does this patch solve your problem?
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.
Here is a patched build. http://www.oersted.co.jp/~emk/2006/01/fb-323142test.zip SHA1 hash: fe7bd3c0fa5e78720fb299a4c9fb3c95429e2d38
(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 :-)
Attachment #210028 - Flags: superreview?(roc) → superreview+
checked-in. Thank you, Kimura-san.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Depends on: 374229
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: