51.47 KB, application/zip
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 (?)
ccing Radha who should know more about this stuff. This seems to be coming up a lot lately....
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
reassinging to new owner of form submission
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.
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? thx
on 2001122703 PC WinXP isn't possible access to https://klient1.ebanka.cz/ebts/version_02/banka.html and no other login pages too. Example: https://klient2.ebanka.cz/ebts/version_02/banka.html https://klient2.ebanka.cz/ebts/version_02/CZ/banka3.html
I have just upgraded to mozilla 0.9.7 and I can't see the page anymore. It doesn't render at all.
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...
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: http://www.ebanka.cz/VNU_OsobniEK.htm or English pages on: http://www.ebanka.com/prise.htm 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? thanks
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 forever. Yours, Jan.
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!
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.
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.
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.
I think, this is same bug as bug #104227.
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.
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.
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 :-( Petr
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.
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
on 2002012304 looks that mobil key access works fine. good job.
The login page is not appearing at all on Netscape 6!!
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. " so: 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.
When tring to login using mobil key. The page will not reload after pressing buttom Autentiza
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?
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.
I have no problem with 0.9.8 (2002020511) but both newer builds I have tested don't work. The latest was 2002030710.
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!
Created attachment 75656 [details] Today's snapshot of the web as saved by Mozilla's save page as complete web page feature
build 2002032019 works fine!
folks, 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
Build ID Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9+) Gecko/2002032603 works fine!
Latest Linux version works as well. Build: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020327
a few more confirmations and this one is ready to be closed WFM
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9+) Gecko/2002032803 works fine!
Well, 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.
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. ******************* apparent WORKSFORME keep open *******************
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.
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.)
verifying per coments