Bug 105274 (ebanka)

the login page into eBanka's internet banking system ceased to work somewhere between 0.9.2 and 0.9.5[form sub]




HTML: Form Submission
16 years ago
15 years ago


(Reporter: Vaclav Dvorak, Assigned: Alexandru Savulov)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: URL Markup changed, URL)


(1 attachment)



16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012
BuildID:    2001101202

On the URL given above, when you enter any two numbers and click OK, you are
asked for confirmation of reloading the page ("The page you are trying to view
contains POSTDATA...."), and whether you then click OK or Cancel, you don't get
past the login page. This worked in 0.9.2 and doesn't in 0.9.5. I think it
worked in 0.9.4 but I am not 100% sure.

Reproducible: Always
Steps to Reproduce:
1. Go to the URL.
2. In the form, enter any two numbers.
3. Click OK.

Actual Results:  See description above.

Expected Results:  Display a page of "the authentication code is invalid" (in
Czech - "Vá?ený kliente, Vá? autentiza?ní k?d je chybný...."). Or let you in the
banking system, of course, if you guessed the right numbers. ;-) You can try it
in Netscape Communicator or Mozilla 0.9.2, it works there.
confirming with win2k build 20011017..

-> From Submission (?)
Assignee: attinasi → rods
Component: Layout → Form Submission
Ever confirmed: true
OS: Linux → All
QA Contact: petersen → vladimire
ccing Radha who should know more about this stuff.  This seems to be coming up a
lot lately....

Comment 3

16 years ago
another me-too as I also use this bank
Works in 0.9.4 and in 2001-09-20-21-trunk Linux build probaly also more recent ones
Doesn't work in 0.9.5 and  at least in 2001-10-01-21-trunk build. also
2001-10-10 does't work. Current CVS is also not working

Comment 4

16 years ago
reassinging to new owner of form submission
Assignee: rods → alexsavulov


16 years ago
Summary: the login page into eBanka's internet banking system ceased to work somewhere between 0.9.2 and 0.9.5 → the login page into eBanka's internet banking system ceased to work somewhere between 0.9.2 and 0.9.5[form sub]

Comment 5

16 years ago
Win98SE/Czech/Java Off: When I type in any L/P, Mozilla warns about reposting
POSTed data and redirects to the login screen, but I believe it's the same bug.
I checked several nightly builds (win32, no installer, no talkback):
2001-09-28-16 works OK, 2001-09-29-08 has this bug.

PS This is the most popular Czech Internet bank and also the only page where I
need IExplorer.

Comment 6

16 years ago
Confirming. I'll see what i can do. Could you use Netscape6.2 or an older
mozilla build (0.9.4) until this gets fixed please?


Comment 7

16 years ago
I did some debugging in JavaScript Debugger. The javascript code on login page
after submitting the login form, creates another form in main frame. The the
script tries to find newly created form, but it does not find it.
I think it was following code (from top_functions.js) called from UrlForm (where
the form was created):

function SubmitForm(a_Frame,a_Form){
var v_cnt0;
var v_cnt1;
for ( v_cnt0=0;v_cnt0<top.frames.length;v_cnt0++ ) {
if ( top.frames[v_cnt0].name == a_Frame ) {

// a_Frame is found just fine
//!! problem is that there are no forms found in the a_Frame, so the function 
// SubmitForm does nothing
// I don't know if the form creation script failed, or the document is just not 
// updated correctly

for (v_cnt1=0;v_cnt1<top.frames[v_cnt0].document.forms.length;v_cnt1++){
if (top.frames[v_cnt0].document.forms[v_cnt1].name == a_Form) {

I highly suspect, that it has something to do with recent form changes (?).
I don't currently have much time to research this, but I hope this could help.



16 years ago
Keywords: nsbeta1

Comment 8

16 years ago
on 2001122703 PC WinXP isn't possible access to
https://klient1.ebanka.cz/ebts/version_02/banka.html and no other login pages too.

Comment 9

16 years ago
I have just upgraded to mozilla 0.9.7 and I can't see the page anymore. It
doesn't render at all.

Comment 10

16 years ago
  I closely examine the bug and I found that mozilla often (not at all cases) 
crash when script try to write on page <meta http-equiv="Content-Type" 
content="text/html; charset=windows-1250"> the setting of charset is problem 
content text/html is oki.
example - following code will crash mozilla into infinity loop:
    <SCRIPT LANGUAGE="JavaScript">
    function callit() {
    var S = '<HTML><HEAD> <meta http-equiv="Content-Type" content="text/html; 
charset=windows-1250"> <TITLE> MOJE4 </TITLE>  </HEAD> <BODY> "Hallo man"  
</BODY> </HTML>';
  <BODY onload="callit();">
  Hello world

Error: uncaught exception: [Exception... "Component returned failure code: 
0x804e03f7 [nsIDOMNSHTMLDocument.write]"  nsresult: "0x804e03f7 (<unknown>)"  
location: "JS frame :: file:///G:/S.html :: callit :: line 7"  data: no]
  the same crash occur on eBanka web pages (fomerly into infinity loop 
rendering login page and now with some editing of scripts doesn't render at 
all - but i belive thet it's the same kind of bug):
Error: uncaught exception: [Exception... "Component returned failure code: 
0x804e03f7 [nsIDOMNSHTMLDocument.write]"  nsresult: "0x804e03f7 (<unknown>)"  
location: "JS frame :: 
http://xxx.xxx.xxx.xx/xxxxx/version_02/CZ/jscode/top_functions.js :: 
closeDocument :: line 190"  data: no]
  <meta http-equiv="Content-Type" content="text/html; charset=windows-1250"> 
written in html file is oki but any time one try to print it through 
document.write - mozilla crash (sience 0.9.5)

Comment 11

16 years ago
Looks like we have to do with two different bugs here. 

I'm testing with build 2002010703 and the testcase posted by Zdenek is a _JS_
_recursion_ that keeps the browser busy. However you can still use the Back/Fwd
buttons to exit his recursion. I didn't observed an application crash though.
As concerning the URL (start page) I cannot see anything anymore on that page.
Also Opera 6.0 is unable to display that page.

Please check if this institution is blocking intentionally the other browsers
and is trying to constrain its customers to use IE or the 4.x version of Netscape.
Please try it with older versions of Mozilla.
Looks more like an evangelization issue.

Setting milestone...
Target Milestone: --- → mozilla1.2

Comment 12

16 years ago
Well,(I'm a customer of this inst. too).They told me:
They support those Browsers: MSIE 4.x and later and NS4.7x and I'm not sure very
much now with NS6.x (but I think they mentioned it also as supported browser, or
at least as their site work with NS6.x)and they don't officialy support Mozilla
browser becouse it hasn't been officialy released yet (full version).
Opera Browser has problems on many sites which I'm visiting although it could
pretend what kind of browser it is.

But I'd prefer to use Mozilla instead of NS6.x, so I don't have experiencies
with NS6.x, but I have them with Mozilla .

I know that 2 mozilla releases was working with this institution web.
Mozilla0.9.4(Gecko/20010913) is working with this site. And I don't exactly
remember the previous one. So the functionality has been lost somewhere between
releases 0.9.4 and 0.9.5.

your testing point should be
this URL:
or English pages on:

where you select fastes connection and if the result paga won't be empty, you
are over the problem.

And Excuse me, couldn't be this bug fixed earlier, please? It was already
WORKING, so that's regresion, and waiting for that fix more then 6 releases, is
strange, isn't it?


Comment 13

16 years ago
Alex: ebanka is not bloking Mozilla, it's a regression, see my comment #5. 
2001-09-28-03 has been working just fine all the time. However, as of 
2002-01-08-03, it works again!!! The redirect problem is gone. (I don't use 
Java, but the JavaScript version just works)

Comment 14

16 years ago
I'm confirming that the build I've downloaded today, which says
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7+) Gecko/20020108
works correctly -- it offers the form, let's me enter my account number
and password and lets me log in.

So if you guys know how it got fixed, this bug could be marked as resolved.
I don't think it is much of evangelization issue. eBanka knows that there
are other browsers and OSes and Zdenek Cerny has an @ebanka.cz email. So
it was more technical than political issue.

Hopefully this version working is more than a positive fluctuation
and we won't lose this functionality again -- yup, NN can be gone

Yours, Jan.

Comment 15

16 years ago
IMO, there was some changes in the eBanka client system, because
of this error was propagated into the 6.2 release of Netscape and
Netscape is oficcialy supported by eBanka. It's possible that the
main reason of this error wasn't discovered. But, it works also
on my home Debian Box and this is important. Bye bug!

Comment 16

16 years ago
Seems true, eBanka has probably changed their login page. It now works with
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120 as well, so
the fix is not specific to the latest builds. I've written to eBanka to
advise if and what changes they had taken -- will post here if I learn
something. The bug in Mozilla is probably still there and I was wrong with
stating that the latest Mozilla build has it fixed -- it's the web page
which got changed, most probably.

Comment 17

16 years ago
Confirming: eBanka suddenly starts working for 

Mozilla 0.9.7 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226

no changes at client side done in order to make it work, there must be a change
at eBanka server side.

It seems to me that there is an unofficial support for Mozilla in eBanka.

Comment 18

16 years ago
eBanka client service told me, that they are aware of Mozilla, however, they can
not gurantee full functionality with it (since there is no "full version
release" of Mozilla yet). They support latest Netscape instead.

So, there is still a "bug or feature" in Mozilla, which symptoms are described
in previous comments, that is worked around at eBanka server side now but
aparently remains in Mozilla code.

Comment 19

16 years ago
I think, this is same bug as bug #104227.

Comment 20

16 years ago
Things change too fast on this page and I miss the initial test case. Is hard to
repair a page that changes that often. Usualy we need to focus on a reduced
testcase that contains the bug, or a detailed description of what went wrong,
but this implies a testcase too. I saw the initial bug on the page after this
bug was reported, however the initial testcase got lost since the "ebanka" guys
changed the page. I would appreciate if someone of you guys could isolate the
bug and create a reduced testcase (and hope that the "ebanka" team doesn't
change again the page. It would be a good ideea to add some of the responsible
guys to the CC list of this bug and recommend them to register for a bugzilla
account. I'm sure that this guys could help mozilla a lot. 

BTW: Netscape 6.2 and Netscape 6.2.1 are official releases that are based on
Mozilla pre-release 0.9.4. (6.2.1 is builded from a modified 0.9.4 release).
Basicly the layout engine is the same with some changes. If they would support
the latest NS 6.2.1 release, I assume that the latest Mozilla 0.9.7 should work
too. If it wouldn't work with 0.9.7 but work with NS6.2.1 I could re-milestone
to 1.0, otherwise I can't do this be cause then I would have to explain this to
the drivers why is it that importatnt, but I have no arguments for that. A
regression from 0.9.4 would be a strong argument. 

Comment 21

16 years ago
I thought this was clear from the very beginning: the thing worked in 0.9.4 but
not in 0.9.5 and onwards, so it _is_ a regression (if I understand what that
word means). Unfortunately, since the web page is now changed (and working), it
is impossible to track this down unless someone saved a backup. I take the blame
as a reporter for not posting a copy. Sorry.

Comment 22

16 years ago
Actually I have original page (and scripts) saved somewhere on my home 
computer, I could try to reduce it to simple test case or post it here (don't 
know if that would be legal). Unfortunately I don't have any spare time until 
next week :-(


Comment 23

16 years ago
I'm sorry, but could not resist: the bug has been reported almost 3 months ago.
The page was the same for even longer time (the reason for the error was not a
change in the page, but in Mozilla itself) - I'm not sure words like 'often' or
'fast' apply here - there were two Mozilla milestones in between.

The change in eBanka has happened few hours after I had sent this bug link to
eBanka client service (this may be a coincidence, of course).

I think that it would be worth for this bug solvers to try contact eBanka for a
contact with eBanka developers. English interface to eBanka is at
http://eBanka.com ; where there is a "write us" link. The eBanka developers
should know, what exactly they changed.

Comment 24

16 years ago
well, about former bug(s):
The page you are trying to view contains POSTDATA....
it cause error this.frames.document has no properties
mozilla just don't yet close some frame and try to write in it (top.frame
["Main"].document point to null) (when mozilla fail to make some code it often 
return a one level up in stack - where was script which try to log in so the 
login page was render again and the message abou post data - it's in IE too 
just go to login page press F5 and u got info about reposting data) this "bug" 
was in 0.9.4 too (and in netscape 6.2) but occur rarely - u can try to simulate 
it when go on login page through button "CONNECT TO FASTEST" or just try a few 
logins pages and some of them probably fail. In mozilla 0.9.7 I see this error 
too, but is almost impossible to respawn it (about 1-2 from 100 attempts). So I 
don't have time to test every former mozilla build to make complete history of 
this bug, but I belive that something in mozilla engine was too slow (when I 
try to detect which frame and script loads and in which order I put some alerts 
in them and the alert's delay cause that error gone - frames was correctly 
closed). The stucture of script was changed because of some "needs". And now 
latest mozilla builds and NN6.x works. There could be some hidden bug - the 
changes in scripts was huge and I may trace something wrong, but I belive that 
I'm right. 
The second bug with meta tag writting - on bugzilla is posted about 5 bugs with 
something about internalizations and language coding, most of them is mark as 
duplicated and I thing that the one mentioned in comment #19 is bug on eBanka 
pages (for now bypassed). about browser support - any browser which is w3c 
compliant is nonofficialy supported :), and in scripts is not used code which 
works only with one browser - JSscripts for IE or some tag and properties only 
for NN (with one exception for IE - but it's security reason because IE cache 
https pages on disk where can be modified :(). but as I said cooperation is 
nonofficial so any special acess to old scripts or even database is not 
allowed. So sorry. U can use old scripts if u have some downloaded, but no 
special contact with eBanka It workers (I know them so trust me :), the error 
occured before script try to connect database so problem is if write of form in 
frame "Main" - old version or in frame "Data" in new version run correctly. I 
hope I help. So long Zdenek Cerny 


Comment 25

16 years ago
on 2002012304 looks that mobil key access works fine. good job. 
Marking nsbeta1-
Keywords: nsbeta1 → nsbeta1-

Comment 27

16 years ago
The login page is not appearing at all on Netscape 6!!

Comment 28

16 years ago
just as I said :
this "bug" was in 0.9.4 too (and in netscape 6.2) but occur rarely - u can try 
to simulate it when go on login page through button "CONNECT TO FASTEST" or 
just try a few logins pages and some of them probably fail. 
hit reload and page will be loaded - this is caused by unclosed frame in 
mozilla (script try to write into some frame defined in banka.html but pointer 
on this frame.document is still null and have no properties). It depends s 
little on connection speed, computer speed,... and at most on your luck :) On 
latest builds od mozilla is this problem very rare - I dunno if this is because 
mozilla is now faster and close all frames at time, or if someone patchet it up 
and frame source wait with processing for close of their parent. 

Comment 29

16 years ago
When tring to login using mobil key.
The page will not reload after pressing buttom Autentiza

Comment 30

16 years ago
When tring to login using mobil key.
The page will not reload after pressing buttom Autentizacni kod and no code is
send to mobil phone. Mozilla stay on page "Váš požadavek je ..." and not reload
back to login page. 
The JavaScript console say 

 Error: uncaught exception: [Exception... "Component returned failure code:
0x80004005 (NS_ERROR_FAILURE) [nsIDOMLocation.hostname]"  nsresult: "0x80004005
(NS_ERROR_FAILURE)"  location: "JS frame ::
https://klient1.ebanka.cz/ebts/version_02/CZ/jscode/top_functions.js ::
createURLStoredProc :: line 853"  data: no]

For all interested in this bug is on page http://www.czilla.org (Czech language)
this like news and in http://forum.czilla.org (Czech language) is opened room in
message board. Is for all who want or need tell something about this outside
Bugzilla (for free discussion).

Comment 31

16 years ago
There were some form submission changes lately, and a few other similar but
unrelated bugs went away.  Can the reporter of this bug check to see if this is
fixed in the latest nightlies?

Comment 32

16 years ago
with current CVS versions of mozilla you get the login screen without problems
and can even submit the ID. But then it stops responding and location has some
strange content "wyciwyg://2//ebts/owa/AUTH3.Login", which seems really strange.
And you don't receive any authentication data. Maybe this bug is fixed and
problems are in other areas (Javascript rewrite?)

On the bright side, the test in #10 now works.
wyciwyg:// used to appear on urlbar for all dynamic JS pages, created using
document.write(). I have changed the behavior so that the urlbar does not show
wyciwyg:// anymore.  see bug 123140. 

Comment 34

16 years ago
I have no problem with 0.9.8 (2002020511) but both newer builds I have tested
don't work. The latest was 2002030710.

Comment 35

16 years ago
The behavious seems to have changed a few times, but it still doesn't work in
0.9.9 (build 2002031008). As of this build and today's version of the page, when
you fill in the numbers and click OK, the URL changes to
https://klient1.ebanka.cz/ebts/owa/AUTH3.Login, the text on the page changes to
say "Dear client, your request is being sent to the system. Please wait." (my
translation) and then nothing at all seems to happen. (Fortunately, 0.9.7 and
0.9.9 can peacefully coexist without complaining.) I will attach a zip of the
web this time so that Mozilla and eBanka don't work against each other, because
it seems from past experience that eBanka might change the web to work around
the bug.

This is a major issue for many of the Czechs. 1.2alpha is way too far! Please, I
beg you!

Comment 36

16 years ago
Created attachment 75656 [details]
Today's snapshot of the web as saved by Mozilla's save page as complete web page feature

Comment 37

16 years ago
build 2002032019 works fine!

Comment 38

16 years ago

please try with a newer build! in the past time we did a lot of changes to the
form submission module and we need feedback. might be that this is not an issue
anymore since the module was redisigned. i see the previous comment reports that
build one of the latest builds work.

let us know please

Comment 39

16 years ago
Build ID Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9+) Gecko/2002032603
works fine!

Comment 40

16 years ago
Latest Linux version works as well.
Build: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020327

Comment 41

16 years ago
a few more confirmations and this one is ready to be closed WFM

Comment 42

16 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9+) Gecko/2002032803
works fine!

Comment 43

16 years ago
Mozilla/5.0 (X11; U; Linux i686; cs-CZ; rv:0.9.9+) Gecko/20020328
works fine with ebanka pages.

But ebanka's pages also works with Mozilla 0.9.8 release and 0.9.7 NOW!

Frankly speaking no one could be sure if it is because you realy fixed the
problem or it is also because ebanka institute change their code of webpages
too. (and they did, see the comments -all- From Zdenek Cerny)

But it works fine with the version of ebanka's webpages they have now.

Comment 44

16 years ago
I suspected changes in their pages too. It might also be that we fixed some
issues due to standards before and we broke this one here. Well I guess that the
bank's web content developers have decided to take mozilla/netscape in their
focus (it might also be that they heard some buzz about future development in
the browser market). Ok, we are not going to close this one, we'll keep it
around with a lower priority.

keep open
Severity: major → normal
Priority: -- → P3
Whiteboard: URL Markup changed
Target Milestone: mozilla1.2alpha → Future

Comment 45

16 years ago
I confirm that in today's build (2002032908 on Linux) the login page works. I am
not able to save the page to compare with the previous version because the "save
page as" dialog doesn't work in this build (and the URL input line and other
things :-( ). However I saved the page with 0.9.9 and unless there's a problem
with Mozilla's cache, the page has NOT changed since the snapshot I made (and
attached to this bug) on 03/22, and 0.9.9 is still not working. (0.9.7 has been
working all the time, I believe.) So I think it is Mozilla that has changed, not
the website's code.


16 years ago
Alias: ebanka

Comment 46

15 years ago
As the original reporter, I propose closing this bug as fixed. This has been
working for a long time and although we don't know exactly what the problem was
or what fixed it, I doubt that it is realistic to expect that "sometime in the
future", someone will come back and do the archaeology to research this in
depth. (I will now try closing it but I'm not sure if Bugzilla will allow me.)
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 47

15 years ago
verifying per coments

Comment 48

15 years ago
You need to log in before you can comment on or make changes to this bug.