Closed Bug 360313 Opened 18 years ago Closed 17 years ago

Java applet password field gains focus but cannot be typed in.

Categories

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

Product:
Plugins Graveyard
Component:
Java (Java Embedding Plugin)
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: jgrubic, Assigned: smichaud)

References

Details

User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.8) Gecko/20061030 SeaMonkey/1.0.6 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.8) Gecko/20061030 SeaMonkey/1.0.6 This is a problem when connecting to the Java applet for St. Bernard Software's iPrism. This applet works fine in Mozilla 1.7.13. It does not work in SeaMonkey and does not work in Firefox 2.0. Because this applet is broken in new versions of Mozilla products, and works fine in older versions, I can only speculate that there has been a change to the code that breaks this. Reproducible: Always Steps to Reproduce: 1. Go to IP for iPrism device 2. Attempt to login; login applet launches 3. Username can be typed but password field cannot be typed in Actual Results: Could not type in password field. Had to cancel the dialog to get back to SeaMonkey's window. Login fails because the correct password cannot be typed in. Expected Results: I should have been able to enter the password and click login. No special configuration; as mentioned, applet works in Mozilla 1.7.13
The issue is encounted in the open source project OpenOCES.org in the applets called OpenSign and OpenLogon. The bug is reported i the projects internal bugzilla: https://www.openoces.org/bugzilla/show_bug.cgi?id=50 The bug is reproducable using the demo pages: https://www.openoces.org/demo/index.html 1. Choose OpenSign or OpenLogon 2. Choose 'Continue' 3. Accept running the signed applet 4. Choose 'Browse..." and select a password protected PKCS#12-fil 5. Choose 'Login' / 'Sign' 6. The password dialog with the problem appears
This bug is also present when using the Danish netbank (www.danskenetbank.dk) as well as the Danish tax authority (www.skat.dk). Firefox 2.0.0.3 - Java 1.5.0_07 (Apple) - Mac OS X 10.4.9
I don't know if this is JEP-related, but I'm CC:ing Steven.
Assignee: general → nobody
Component: General → Java: OJI
Product: Mozilla Application Suite → Core
QA Contact: general → java.oji
This does seem to be JEP-related ... in the sense that I'm going to have to find a workaround for it. Ultimately it seems to be yet another bug in Apple's Cocoa-Carbon interface. I was able to reproduce this problem in Firefox 2.0.0.3 and Seamonkey 1.1.1, but not in Camino 1.0.4 (all on OS X 10.4.9).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hmm, I wonder how wide-spread the issue is. That is, if there's a lot of banks that are using those applets...
If it were very widespread, I think we'd have heard about it before. I don't believe this is a recent problem (a regression).
Right, not a real blocker then. Seems to work on 1.7.13, according to comment #0. So, it has probably been there for some time...
> Seems to work on 1.7.13 I'll bet that this was with Java 1.3.1 (i.e. without the JEP). With the JEP, this problem has probably existed since the very beginning.
Sounds like a duplicate of bug 353160 related to Firefox 1.5.0.7
> Sounds like a duplicate of bug 353160 related to Firefox 1.5.0.7 Nope. The symptoms are similar, but that bug is completely unrelated. And in any case, that bug's been fixed. I've now managed to track down this bug and fix it in my current version of the Java Embedding Plugin. Turns out it's actually a bug in the JEP (a flaw in a workaround for various Apple bugs). Also (interestingly) it doesn't happen on OS X 10.2.8 and 10.3.6 -- only on 10.4.X and (presumably) above. I hope to release a new JEP (one containing this fix) in the next couple of weeks. With luck I'll release it in time for it to be bundled with Firefox 2.0.0.4 and 1.5.0.12.
Steve, I can confirm that this bug DOES occur in MacOS X 10.3.9. My initial report was made on that version of the OS (and I am still running it).
(In reply to comment #11) Then the bug you originally reported may be different from the one reported in comment #1 above. Please test with current versions of the various Mozilla.org browsers (Firefox 2.0.0.3/1.5.0.11, Seamonkey 1.0.8/1.1.1) to be sure your problem still happens with them. Also test a current version (1.0.4 or 1.1b) of Camino. But if I'm right (and your problem is a different one), you (or someone) will ultimately need to provide us with a publicly accessible test case. Otherwise there's no way for us to fix the problem. By the way, I just tested the second URL at https://www.openoces.org/demo/index.html again in OS X 10.3.9 with Firefox 2.0.0.3 -- the problem reported in comment #1 doesn't happen.
I've just released a new version (0.9.6.1) of the Java Embedding Plugin that fixes the problem described in comment #1. For more information see bug 376395.
Depends on: 376395
This problem still persists. It is a problem on several Danish webpages (a few mentioned above), since they all use a central login page: https://login.service.csc.dk I have found one crude workaround: 1) type your password in e.g. TextEdit and copy the password. 2) move the cursor over the text field, right click and paste. Click ok. Note that the above trick will not work using paste from the menu, even though the field is active. Firefox 2.0.0.3; Java 1.5.0_07; MacOS 10.4.9
You were using a version of the Java Embedding Plugin that doesn't contain the fix for this bug (as reported in comment #1) -- Firefox 2.0.0.3 bundles JEP 0.9.6, but the first version of the JEP that contains the fix is 0.9.6.1. Download and try Firefox 2.0.0.4 RC2 (which bundles JEP 0.9.6.2): ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2.0.0.4-candidates/rc2
Can people seeing this bug verify that it is fixed in Firefox 2.0.0.7?
Assignee: nobody → smichaud
Component: Java: OJI → Java Embedding Plugin
QA Contact: java.oji → java.jep
I use 2.0.0.11 and the bug still persists
Please provide a publicly accessible URL that demonstrates the problem, and steps to reproduce.
(In reply to comment #18) > Please provide a publicly accessible URL that demonstrates the > problem, and steps to reproduce. From other (danish) forums I understand that Henrik Jepsen encountered the issue on the danish tax authority selfservice site. Unless you have a danish public X.509-based id (OCES) you can't reproduce it here. But the tax authority uses the same applet as described in comment #1, so it should work as a demonstration. Maybe Henrik Jepsen can confirm, that he encouter the problem at the OpenOCES.org demo-pages as well???
I confirm that the problem (and the copy paste fix) consists on the OpenOCES.org demo pages
I just tried the demos at https://www.openoces.org/demo/index.html (from comment #1) and had no problems. I could type whatever I wanted into the password prompt dialog, and stars appeared as I typed. My password was rejected (even when I typed the correct one for the *.p12 file that I was using), and the password prompt came up again. But I assume that this is a limitation of the demos. I tested using Firefox 2.0.0.12 (the current version) on OS X 10.4.11 and 10.5.1.
The Password prompt field accepts you type text and the stars appears. But as you write above, it rejects the password leaving the field blank. If you copy and paste the password from textedit it accepts the password and continues. The problem on the demo-pages is the same on danish tax authority selfservice site. But is seems to be an OSX issue only. In IE7 and Firefox for Windows I have no problems just typing in my password, but in my OSX browsers the same problem in each browser. OS X 10.5.1 Firefox 2.0.0.12 Safari 3.0.4 (5523.10.6) Camino 1.5.5 Opera 9.25 (3721) - cant type text in to field, but works when copy / paste of password.
In my tests, my (correct) password was rejected even when I pasted it into the Password field. But that's probably because I've been using a *.p12 file that I created myself (using OpenSSL's CA.pl). And in any case, what you (Henrik) said in comment #22 shows two things: 1) The problems you (and other users of the Danish tax authority site) are completely unrelated to the problem originally reported here (which was fixed long ago). 2) These problems have nothing to do with the Java Embedding Plugin or with any Mozilla.org browser -- since they also happen using Safari. There may be a bug in Apple's implementation of Sun's JVM. Or there may be a problem with the OpenOCES applet(s). Please open bug reports with Apple and with OpenOCES.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
> But that's probably because I've been using a *.p12 file that I > created myself (using OpenSSL's CA.pl). I should have said: But that's probably because I've been using a *.p12 file containing certs and a key that I created myself (using OpenSSL's CA.pl).
Regarding the danish authority login, I've found out that if you change the Mac OS X Java version from Java5 to 1.4.2 using the Java preferences, you can only login if you manually click the 'ok' button with the mouse. If you press the enter button, it just reloads the password-windows. This is using Safari and Firefox 3.0b5. So make sure you're running the correct java version.. Java6 that was released today totally breaks the login-form, and my netbanking for that sake.. -.-
Component: Java Embedding Plugin → Java (Java Embedding Plugin)
Product: Core → Plugins
Product: Plugins → Plugins Graveyard
You need to log in before you can comment on or make changes to this bug.