Closed Bug 95973 Opened 23 years ago Closed 23 years ago

backspace and delete keys don't work in homebanking applet

Categories

(Core Graveyard :: Java: OJI, defect)

Product:
Core Graveyard
Component:
Java: OJI
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.9

People

(Reporter: mozilla, Assigned: margaret.chan)

References

(
URL
)

Details

(Keywords: platform-parity)

Attachments

(6 files)

reduced textfield for applet
7.75 KB, text/plain
Details
HTML testcase
1.86 KB, text/html
Details
the test applet
1.08 KB, text/plain
Details
Correct HTML testcase
101 bytes, text/plain
Details
Modified applet
1.16 KB, text/plain
Details
test case with 'object' tag
141 bytes, text/plain
Details 
Whenever I use mozilla (Build 2001080104) on my homebanking applet, the delete
and backspace keys are simply ignored. To reproduce:

- go to https://banking.lbbw.de/
- move the mouse in applet window to initialize
- type anything in one of the fields (preferrably digits in the first field that
says "Kontonummer:", ie. account number)
- try to delete any digit using the delete or backspace keys

=> nothing happens

This is particularly, umm, uncomfortable when you have filled out a bank
transfer form and need to correct a single character near the end. But you can't
check that without a bank account at LBBW ;-)

And yes: it worked fine with Netscape 4.x.
->oji
Assignee: asa → edburns
Component: Browser-General → OJI
QA Contact: doronr → pmac
I have the same problem with my bank at

https://banking.sonline.de/sparkasse-ac/
This does not happen in WinME, so it appears to be Linux only. You can mark the
erroneous typing with your mouse and overwrite it, but that is hardly an
acceptable workaround.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: pp
Seen on linux redhat 6.2 on commercial build (2001-09-05-08-trunk). Yes,
the delete and backspace are not working.
However, yes, it works fine on netscape 4.x.

Reassign to Joe as I'm leaving the role of OJI module owner.
Target Milestone: --- → mozilla0.9.5
Ressign to Joe Chou, as I am no longer working officially on OJI.
Assignee: edburns → joe.chou
Target Milestone: mozilla0.9.5 → mozilla0.9.6
I'm not sure whether this is a separate bug or not. Just have a look at the
homebanking applet at (swirl your mouse to start it):

https://banking.sonline.de/sparkasse-ac/

The text you type into the textfields is cut off by three quarters, rendering
the applet nearly useless.

This happens with 0.9.4 under Linux. Just prod me if you think this is a
separate bug, I will gladly file it.
Keywords: 4xp
Re-assign to mtchan.
Assignee: joe.chou → mtchan
Target Milestone: mozilla0.9.6 → mozilla0.9.9
I think this is not Mozilla bug: I reduced apllet from https://banking.lbbw.de
and browsed it with appletviewer on Linux and Solaris.
On Solaris appletviewer (for JRE1.2 and JRE1.3.1 and JRE1.4) works correctly:
backspace and delete keys work. On Linux: appletviewer of JRE1.2 and JRE1.4
works correctly and JRE1.3.1 works incorrectly -- backspace and delete
keys doesn't work. Mozilla doesn't handle any key events which occur
in applet area so browser doesn't influence on behaviour of applet 
in case of key events. So if user installs JRE1.4 this bug willn't be
reproducible (I checked it). So my suggestion either
	to file bug against JRE1.3.1 on Linux and close bug as invalid
or
to close bug as fixed (fixed in JRE1.4)
To create reduced test case create applet which
displays BXField.
Siggi and Margaret would you please respond to comment #8 ?
Since it is fixed with JRE1.4, I am going to close this bug as resolved fixed. 
If there is any objection, please reopen it.  Margaret
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Well, I have to object since both URLs given in this bug do not work at all with
JRE 1.4.  It is hardly any help to know that this bug might be fixed in 1.4 if I
cannot use online-banking at all...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
To Diego: I checked once more both URLs mentioned in the description: 
I used JRE1.4.0: 
java version "1.4.0-beta3"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta3-b84)
Java HotSpot(TM) Client VM (build 1.4.0-beta3-b84, mixed mode).

So for both URLs applets work fine and bug is NOT reproducible. 
And with JRE1.3.1 bug is reproducible.

Can you load any other applet (java.sun.com) with JRE1.4.0 ?
Can you load any other htpps: site ?
Are there any exceptions in Java Console or some error
messages with JRE1.4.0 ?
What Mozilla build do you use ?


I am sorry, there was a lot of information missing from my comment.  Here it goes:

I am using 2001113006 with JRE 1.4 beta 3 and a freshly created profile.  I use
Debian and converted the rpm into a deb using alien.  I followed these
instructions to get java 1.4 working at all:


To get mozilla to work with JDK1.4b3 on linux, do the following:

cd MOZ_HOME
./run-mozilla.sh ./regxpcom PLUGIN_HOME/libjavaplugin_oji140.so

where MOZ_HOME is your mozilla install dir and PLUGIN_HOME
is your JDK install dir + /jre/plugin/i386/ns610

Sorry if the description sounds weird, but I was trying to avoid linewrap
triggering for the "./run-mozilla" line. ./run-mozilla.sh
and ./regxpcom are part of the same command and are not separate
commands.


I have no problems with java applets on other sites and I can also view other
https pages.  I do get errors on the java console.

At the page https://banking.sonline.de/sparkasse-ac/ I get:

Uncaught error fetching image:
java.lang.NullPointerException
	at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:555)
	at
sun.net.www.protocol.http.HttpURLConnection.getHeaderField(HttpURLConnection.java:1092)
	at java.net.URLConnection.getContentType(URLConnection.java:384)
	at sun.net.www.protocol.https.HttpsURLConnectionImpl.getContentType(DashoA6275)
	at sun.awt.image.URLImageSource.getDecoder(URLImageSource.java:113)
	at sun.awt.image.InputStreamImageSource.doFetch(InputStreamImageSource.java:254)
	at sun.awt.image.ImageFetcher.fetchloop(ImageFetcher.java:217)
	at sun.awt.image.ImageFetcher.run(ImageFetcher.java:185)
Uncaught error fetching image:
java.lang.NullPointerException
	at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:555)
	at
sun.net.www.protocol.http.HttpURLConnection.getHeaderField(HttpURLConnection.java:1092)
	at java.net.URLConnection.getContentType(URLConnection.java:384)
	at sun.net.www.protocol.https.HttpsURLConnectionImpl.getContentType(DashoA6275)
	at sun.awt.image.URLImageSource.getDecoder(URLImageSource.java:113)
	at sun.awt.image.InputStreamImageSource.doFetch(InputStreamImageSource.java:254)
	at sun.awt.image.ImageFetcher.fetchloop(ImageFetcher.java:217)
	at sun.awt.image.ImageFetcher.run(ImageFetcher.java:185)


At https://banking.lbbw.de I get:

Version 2.02 - 2001.11.16
Direkt-Brokerage-URL:  https://brokerage.LBBW.de/
OS:Linux 
Browser:Sun Microsystems Inc.
Load Textfile: https://banking.lbbw.de/lbdirekt/ib200/german.txt
MandantenNr=1 BLZ=60050101BLZ_1
Load Hinweisfile: https://banking.lbbw.de/lbdirekt/ib200/hinweis.txt
Load Hinweisfile: https://banking.lbbw.de/lbdirekt/ib200/hinweis.txtfalse
TemplatePath: https://banking.lbbw.de/templatesneubase/templates_LBBW/
Load Graphic: https://banking.lbbw.de/graphics/bild_oben_neu.jpg
Uncaught error fetching image:
java.lang.NullPointerException
	at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:555)
	at
sun.net.www.protocol.http.HttpURLConnection.getHeaderField(HttpURLConnection.java:1092)
	at java.net.URLConnection.getContentType(URLConnection.java:384)
	at sun.net.www.protocol.https.HttpsURLConnectionImpl.getContentType(DashoA6275)
	at sun.awt.image.URLImageSource.getDecoder(URLImageSource.java:113)
	at sun.awt.image.InputStreamImageSource.doFetch(InputStreamImageSource.java:254)
	at sun.awt.image.ImageFetcher.fetchloop(ImageFetcher.java:217)
	at sun.awt.image.ImageFetcher.run(ImageFetcher.java:185)

I will retest this with different builds tomorrow.
To Diego: would you please compile reduced testcase (which is in Attachment
#59320 [details]), create simplest html and test it with JRE1.4.0 beta3. 
If 'delete' and 'backspace' keys work OK would you please close bug as FIXED.

Exceptions you got do not concern 'delete' and 'backspace' keys.
It is possible to open new bug with another summary and another description.
So I think that this bug is fixed.
Attached file HTML testcase — 
Here is the HTML that Sergey provided me with to test the bug.
Attached file the test applet — 
The last piece of the testcase.
Unfortunately I still cannot execute the applets.  I tried the testcase provided
by Sergey with no success.  I put all three files in /tmp/, compiled both java
files and browsed to test.html, the testcase.  I get the following errors in the
java console:

java.security.AccessControlException: access denied (java.io.FilePermission
/lbdirekt/ib200/MainApplet.class read)
	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:273)
	at java.security.AccessController.checkPermission(AccessController.java:404)
	at java.lang.SecurityManager.checkPermission(SecurityManager.java:545)
	at java.lang.SecurityManager.checkRead(SecurityManager.java:890)
	at java.io.File.isDirectory(File.java:701)
	at
sun.plugin.net.protocol.file.PluginFileURLConnection.connect(PluginFileURLConnection.java:74)
	at
sun.plugin.net.protocol.file.PluginFileURLConnection.initializeHeaders(PluginFileURLConnection.java:92)
	at
sun.plugin.net.protocol.file.PluginFileURLConnection.getContentLength(PluginFileURLConnection.java:141)
	at sun.applet.AppletClassLoader.getBytes(AppletClassLoader.java:229)
	at sun.applet.AppletClassLoader.access$100(AppletClassLoader.java:42)
	at sun.applet.AppletClassLoader$1.run(AppletClassLoader.java:143)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.applet.AppletClassLoader.findClass(AppletClassLoader.java:140)
	at sun.plugin.security.PluginClassLoader.findClass(PluginClassLoader.java:191)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:309)
	at sun.applet.AppletClassLoader.loadClass(AppletClassLoader.java:114)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:265)
	at sun.applet.AppletClassLoader.loadCode(AppletClassLoader.java:470)
	at sun.applet.AppletPanel.createApplet(AppletPanel.java:551)
	at sun.plugin.AppletViewer.createApplet(AppletViewer.java:1610)
	at sun.applet.AppletPanel.runLoader(AppletPanel.java:480)
	at sun.applet.AppletPanel.run(AppletPanel.java:293)
	at java.lang.Thread.run(Thread.java:539)
Attached file Correct HTML testcase — 
This is correct reduced HTML testcase
I'm sorry, I sent to Diego incorrect HTML testcase. I created reduced
HTML testcase (Attachment #60477 [details]). Diego, please try to load applet
with this testcase.
I'm not sure if we can call this progress, but I can load the applet with JRE
1.3.1 (blackdown) and 0.9.6 but I cannot type any text into it at all.  With
java 1.4 I get no applet and the following error on the java console:

java.security.AccessControlException: access denied (java.io.FilePermission
/TestApplet.class read)
	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:273)
	at java.security.AccessController.checkPermission(AccessController.java:404)
	at java.lang.SecurityManager.checkPermission(SecurityManager.java:545)
	at java.lang.SecurityManager.checkRead(SecurityManager.java:890)
	at java.io.File.isDirectory(File.java:701)
	at
sun.plugin.net.protocol.file.PluginFileURLConnection.connect(PluginFileURLConnection.java:74)
	at
sun.plugin.net.protocol.file.PluginFileURLConnection.initializeHeaders(PluginFileURLConnection.java:92)
	at
sun.plugin.net.protocol.file.PluginFileURLConnection.getContentLength(PluginFileURLConnection.java:141)
	at sun.applet.AppletClassLoader.getBytes(AppletClassLoader.java:229)
	at sun.applet.AppletClassLoader.access$100(AppletClassLoader.java:42)
	at sun.applet.AppletClassLoader$1.run(AppletClassLoader.java:143)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.applet.AppletClassLoader.findClass(AppletClassLoader.java:140)
	at sun.plugin.security.PluginClassLoader.findClass(PluginClassLoader.java:191)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:309)
	at sun.applet.AppletClassLoader.loadClass(AppletClassLoader.java:114)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:265)
	at sun.applet.AppletClassLoader.loadCode(AppletClassLoader.java:470)
	at sun.applet.AppletPanel.createApplet(AppletPanel.java:551)
	at sun.plugin.AppletViewer.createApplet(AppletViewer.java:1610)
	at sun.applet.AppletPanel.runLoader(AppletPanel.java:480)
	at sun.applet.AppletPanel.run(AppletPanel.java:293)
	at java.lang.Thread.run(Thread.java:539)
Diego, I think I kn0ow why you couldn't type any characetr into text field
in case of JRE1.3.1: BXField allow to type only numericals NOT other characters.
Please try to type something like '123'.
About JRE1.4.0: can you load some other applet ?

I tried again and I can type numbers into the textfield with JRE1.3.1 (Sun and
blackdown), but delete and backspace keys do not work.  With JRE1.4.0-beta3 the
applet refuses to load giving the errors described above on the java console.  I
tried about 10 pages with java applets (the dupes in bug 103461), all without
problems.  Everything except the testapplet and homebanking works with 1.4.  All
tests done with milestone 0.9.6.
I finally managed to make the applet work locally.  I stumbled over bug 84760
(extra "/" appears in file picker dialog).  It is still no use to me, since both
homebanking applets do not work with JRE 1.4... sigh.  But these are other bugs
apparently.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
I just opened bug 114201 about the homebanking applets not loading.
Just tried again with Netscape 4.77 and there I have no problems whatsoever with
any of JRE 1.3.1_01, 1.4.0-beta3 or blackdown 1.3.1.  This is definetely a
mozilla bug ---> REOPEN
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This is DEFINETELY NOT Mozilla bug. Diego, how do you know
that JRE used by Netscape is 1.3.x or 1.4.0-beta3 ?
As far as I know only when 'object' tag is encountered and
'type' attribute of this tag is set to something like:
'type=application/x-java-applet;version=1.3.1' then JRE 1.3.1 is used.
When 'applet' tag is encountered or version of JRE is not set
in 'type' then the default JRE is used. The default JRE for Netscape is
1.1.5. I modified code of test applet and know it shows (in Java Console)
the version of java is being used. The modified applet I'll attach to bug
description. 
Please test it once again and check the java version. One more way to check that
this is java bug is to run the appletviewer for JREs: 1.1.x, 1.2.x, 1.3.x and
1.4.0-beta3. I'll also attach Object.html with 'object' tag.
Attached file Modified applet — 
In this applet the java version is printed to Java console.
Test case with 'object' tag
I was apparently fooled by the output of about:plugins..  After installing 4.77
without java support the problem recurred with blackdown JRE 1.3.1.  I am now
resolving this bug for good, promised.  Sergey, thanks for your patience.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
This bug is fixed based on Diego's comment. Please refer to
http://bugzilla.mozilla.org/show_bug.cgi?id=114201 for further details.
Status: RESOLVED → VERIFIED
FYI, I just installed 1.3.1_03 and it works fine.  This is great news since 1.4
does not work with Mozilla at the moment.
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: