Closed Bug 181440 Opened 22 years ago Closed 21 years ago

ubs.com - E-Banking broken because of regression in processing forms (no action attribute)

Categories

(Tech Evangelism Graveyard :: German, defect, P1)

Product:
Tech Evangelism Graveyard
Component:
German
Platform:
x86
All
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: Erich.Iseli, Unassigned)

References

(
URL
)

Details

(Keywords: regression, testcase)

Attachments

(2 files, 1 obsolete file)

Screenshots of the expected and the buggy behavior
44.53 KB, image/png
Details
Form without action attribute
11.57 KB, text/html
Details 
This bug is happening with the nightly of 2002-11-13-21 on Linux. I didn't try
it on other recent builds, nor on other platforms. But it works with Mozilla
1.1. That's why I'm marking this as a regression, and it's critical because it
completely breaks the UBS e-banking service.

Steps to reproduce
1. Load the URL http://www.ubs.com/g/ebanking/classic/demo.html (this is a demo
   account which allows you to test their system - and for our case, to find out
   where the bug exactly happens.
2. Click the button "Start the UBS e-Banking Demo"
   => you get a page in German. If you want to switch to English, proceed with
      the next steps, otherwise, skip to step ...
3. Click on "Sprache" in the top navigation
4. Select English or your preferred language
5. On the left hand navigation, select "Payments"
6. On the modified left hand navigation, select "Orange/Blue payment slip"
7. In the right frame, you get a list of accounts. Select any one of them which
   doesn't have a negative balance. For example:
    230 638.917.02X    DEMO E-BANKING     TOBROSA AG     CHF    20'697.83
8. Now you get an orange payment slip in the right frame. Fill in the following
   fields with these values:
   Account: 01-10923-9
   Amount: 100
   Reference No.: 1100777
9. Click on verify

Result:
You get the list of the accounts again

Expected result
You should get the same payment slip, but without fields. The text you typed in,
should be formatted in the following manner:
   Account: 01-010923-9  (a leading 0 in the middle number)
   Amount: 100.00        (.00 appended)
   Reference No.: 00 00000 00000 00000 00011 00777
              (a lot of leading 0's and a space every 5 digits from the right)
At the bottom of the payment slip, you should have a "Submit" button, and when
clicking on it, you should get a confirmation screen, saying:
"Your order has been successfully received. It will be executed on (date),
provided sufficient credit is available and the order was transmitted within the
UBS acceptance deadline."

I will attach an image showing the form as it should be filled in, and then on
the left hand of the image the expected results, on the right hand, the buggy
results.
As mentioned in the comment #0
An idea of when this regressed would be nice...  I have a bunch of old linux
nightlies around if you want to try to narrow down the regression time.  Please
let me know.
I could reproduce it with a self-built Mozilla from 2 days ago. I'll see if I
can reproduce it with earlier code tonight.
I can't login to the Netscape Network, but I don't know if this is the same bug.
 This only started happening with today's 2002-11-22-08 build, and wasn't in the
2002-11-21-08 build.
I think this is a cookie issue. I am having problems with bugzilla. Here's what
I see.

- Delete cookies.txt file
- Start Mozilla
- Go to bugzilla and sign in.
- Go to any bug. you'll see that bugzilla doesn't recognize you. It doesn't
bring up the Sign Off/Prefs link at the bottom.

I see that Mozilla doesn't seem to save the  Bugzilla_login cookie no matter how
many times I login. It saves  Bugzilla_logincookie though. 

On yahoo.com, Mozilla saves 2 cookies from .yahoo.com domain but fails to save
one from .www.yahoo.com which results in inability to login and check mail.
*** Bug 181510 has been marked as a duplicate of this bug. ***
I don't think this is form submission, but at the same time there weren't any
cookie changes last night.  Is this a regression from Darin's bug 157133?  Sorry
to point fingers, I'm really grasping for straws here.
This did break for me between Linux builds 2002112108 and 2002112208.  So that
points to a recent checkin.

Comments tend to point that this is a cookie issue. Changing component and
Summary accordingly.

Note that on my 2002-11-13 build, I have the problems of cookies getting lost
after each session (no I don't use the pref that expires the cookies after each
session), so almost every bug I file I have to re-login (in bugzilla). HOWEVER:
I don't have any problems with yahoo mail. So probably, this issue started
regressing before 2002-11-13, but got even worse afterwards.
Component: Form Submission → Cookies
Summary: UBS E-Banking broken because of regression in cookie or form handling → UBS E-Banking broken because of regression in cookie handling
There are no cookie checkins in the range mentione in comment 8.  There are no
form submission checkins either.  There's the checkin for bug  180951 and that
for bug 157133 that may be remotely related.

Please pick a component for this bug -- the assignee and component do not match.
-> me (investigating...)

i noticed similar problems on hotmail
Assignee: alexsavulov → darin
Qa > tever
Assignee: darin → alexsavulov
OS: Linux → All
Priority: -- → P2
Hardware: PC → All
Owner > Morse
Assignee: alexsavulov → morse
QA Contact: vladimire → tever
Even though it's not cookies (there were no cookie checkins) I can investigate
but I don't have a recent build.  Darin, let me know if you are still
investigating in which case I won't bother doing a build.  If you've given up on
it, then I'll take it over.
This could very well be darin's checkin at fault. I synced my CVS tree to 21 Nov
23:00 PST and it works now. Simply backing out darin's checkin didn't work
though, it gave me compilation errors.
i'm still investigating.. will give an update shortly.
OS: All → Linux
Priority: P2 → --
Hardware: All → PC
I'm having the same problem with any site using cookies for auth:  yahoo mail
for example.
Attached patch v1 patch (obsolete) — — Splinter Review 
indeed a regression from my HTTP channel changes.  given:

  Set-Cookie: x=1
  Set-Cookie: y=1

we'd end up ignoring the first Set-Cookie header (overwriting it actually with
the second header).  the patch is really trivial.
-> me
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → mozilla1.3alpha
Attachment #107182 - Flags: superreview?(bzbarsky)
Attachment #107182 - Flags: review?(morse)
owner --> darin, since he has a fix.
Assignee: morse → darin
Status: ASSIGNED → NEW
Summary: UBS E-Banking broken because of regression in cookie handling → UBS E-Banking broken because of regression in http headers
Attachment #107182 - Flags: review?(morse) → review+
Attachment #107182 - Flags: superreview?(bzbarsky) → superreview+
fixed-on-trunk
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
*** Bug 181567 has been marked as a duplicate of this bug. ***
*** Bug 181580 has been marked as a duplicate of this bug. ***
Maybe part of the problem was fixed with the patch, however I still see exactly
the same bug, as described in commennt #0. Reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Erich, which build are you using?
Even though I just downloaded the latest 11/23 build the build number still
shows 202112208 (win32)  that may be the problem, the dailies are horked.

I blame leaf.

My Citibank account isn't letting me in but IE is, so the cookie problem
persists in the latest builds.  
sorry, make that 2002112208 win32

I blame the booze.
*** Bug 181648 has been marked as a duplicate of this bug. ***
marking FIXED.

iirc: the links to download the latest nightly build is not updated over the
weekend b/c the weekend builds are not thoroughly smoketested.  if a weekend
build contained some HUGE regression that resulted in dataloss, it might go
unnoticed until monday.  so, be thankful that you got the 11/22 build instead of
the 11/23 build ;-)
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
*** Bug 181688 has been marked as a duplicate of this bug. ***
So this bug is fixed, but the nightlies are broken until Monday?
no, the 11/23 build has the fix, but the nightly builds available at:

http://ftp.mozilla.org/pub/mozilla/nightly/latest-trunk/

are only updated on weekdays.
or i may be mistaken... but at any rate, i wouldn't suggest downloading a
weekend build.
I'm experiencing this On win32 2002112208, although this bug is fixed, I just
wanted to make a note here of that.  I'll of course be updating to the nightly
on monday.
NorthMan: your build is too old. this bug was fixed after that nightly was made.
please update to a newer nightly. thanks. comparing the date when a bug was
marked fixed to the date of the nightly may be useful before complaining in the
public.
Blocks: 181738
Christian, INI, reread my original comment, and refer to comment 33.  Bug owner
suggested to /not/ upgrade to a weekend build.  
*** Bug 181773 has been marked as a duplicate of this bug. ***
*** Bug 181738 has been marked as a duplicate of this bug. ***
Cookies needs to be added to summary to reduce new dupe count.
Ok, adding "cookies don't get saved" to the summary
Summary: UBS E-Banking broken because of regression in http headers → UBS E-Banking broken because of regression in http headers (cookies don't get saved)
*** Bug 181777 has been marked as a duplicate of this bug. ***
> Bug owner
> suggested to /not/ upgrade to a weekend build.  

he did indeed. however, you can not expect this to be fixed in an earlier build.
wait until monday, if you don't want weekend builds.
*** Bug 181799 has been marked as a duplicate of this bug. ***
Summary: UBS E-Banking broken because of regression in http headers (cookies don't get saved) → UBS E-Banking broken because of regression in processing http set-cookie headers
*** Bug 165326 has been marked as a duplicate of this bug. ***
*** Bug 181952 has been marked as a duplicate of this bug. ***
*** Bug 181962 has been marked as a duplicate of this bug. ***
Obviously, Darin's checkin on 2002-11-21
http://bugzilla.mozilla.org/show_bug.cgi?id=157133#c45
brought a big cookie problem to the light. And this has been fixed.

But this bug is still not fixed, and I would have been surprized if it had,
since I reported it from a 2002-11-13 build. So the checkin that produced that
regression happened before that date.

Now what I'm seeing when sending the form is not another list of accounts, but
it opens the same frameset inside the frameset. And it goes on like that. No
cookie problem though, (I guess), since I compared the cookies saved with
Mozilla 1.1 and they are identical with those saved with the 2002-11-25 build
I'm testing with now.

Reopening
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
removing dependency, since bug has been marked dupe of this.
No longer blocks: 181738
whoa!  what a mess... seems like in the process of jumping on the cookie
regression, i somehow found this bug, and co-opted it.  wacky!  i should learn
to read bug summaries :-/

-> back to form submission
Assignee: darin → alexsavulov
Status: REOPENED → NEW
Component: Cookies → Form Submission
QA Contact: tever → vladimire
Changing back the summary to forms, since now I don't think it's a cookie issue
any more.
Summary: UBS E-Banking broken because of regression in processing http set-cookie headers → UBS E-Banking broken because of regression in processing forms
This bug currently has 11 dupes. Of the 11, 5 have cookies in their summary, and
5 have login trouble in their summary. Do they need to be unduped? If not, then
the keyword "cookies" needs to be in the summary for searches to find.
mrmazda@ij.net, ok, you're right. Putting back the word cookie, because of the dups.
Summary: UBS E-Banking broken because of regression in processing forms → UBS E-Banking broken because of regression in processing forms and cookies
Probably could use further tweaking. It isn't really about UBS E-Banking (narrow
impact; unlikely search term). It's about broken HTTP header handling breaking
cookies and forms processing, preventing e.g. login (broad impact; likely search
terms login, cookies, forms).
Although I am normally against morphing bug reports, due to all the dups I think
we should do so in this case.  Keep this bug report as the defining one on the
problem introduced on November 22 and allow all the dups on it.  Then reopen
another (clean) bug report on the original problem that was reported here.
Yahoo mail, hotmail and netscape mail works fine now (using build 2002112607)
but can't verify UBS e-banking because step 7 return an error: "You have no
authorized account for this service".
I have the same problem using my e-banking account since 1.2Beta (now using
1.2final 20021126 - same problem).
To reproduce try https://meine.deutsche-bank.de/mod/WebObjects/dbpbc and try to
login. Take care to enter the right number of digits for each field, as
described next to them. All fields numeric values only. The error message says
that they tried to place a cookie which was not accepted.
For I'm using Win2K (and some other reporters too), OS should be changed from
Linux to All
In addition to commet 56 it's maybe of interest that I didn't encounter problems
with other sites and the cookie which I mentioned before has expire "at end of
session"
So maybe it's still a cookie issue. The difference is that the other issue was
on http, but this one is on https. Did the patch really fix all headers, or only
http headers?
Frank, Deutsche Bank is bug 171235.
investigating. first i suspected something related to bug 138957 and bug 147878
but is not. will accept the bug if is really FS.
Erich: the patch (attachment 107182 [details] [diff] [review]) effects both HTTP and HTTPS content equally.
On #56, #58 and #61: The Problem with deutsche-bank is th following:
They send the cookie attached to a httpS://meine.deutsche-bank.de/ request.
Mozilla receives the content *and* the cookie. Now in the Cookie-Manager
you can see:

Name:          ID_STR
Information:   XYZABCXYZ
Host:          meine.deutsche-bank.de
Path:          /mod/WebObjects/dbpbc
Secure Server: ***NO***                ??? !!!
Expires:       End Of Session

Now my guess: Mozilla builds a match string somewhat like follows from the
above information:

  "http://meine.deutsche-bank.de/mod/WebObjects/dbpbc" 

But since all subsequent requests go to httpS://meine......
the cookie will never be transmitted back to the deutsche-bank server.
No, the deutchebank problem has nothing to do with https and is not a mozilla
problem.  It is a problem on their site as explained in bug 171235 comment 21.

Please address further deutchebank comments in bug 171235 rather than here.
Flags: blocking1.3a?
Flags: blocking1.3a? → blocking1.3a-
Darin,

are you still on this one? want to take it away from me? 
alexandru: sure, i can try to take another look, but i'm actually not clear on
what the current problem is... seems like there is a lot of noise in this bug
report.  does the original problem summary still apply?  Erich?
Darin, the description in comment #0 still applies, yes. I don't know what the
problem is though. Is it cookies? I doubt: I compared the cookies set in Moz 1.1
and in the latest nightly and they are identical. At least in the cookie manager.

What I know is that when I submit a form, the result I get is unexpected. Which
means that the data sent to the server is incorrect.. That's why I'm thinking
it's a forms-processing bug. But I cannot tell more.
Flags: blocking1.3b?
Keywords: testcase
Reproduced on 11/21 Trunk build, Red Hat 7.3.
The steps in comment 0 can still be reproduced and demonstrate a problem with my
current trunk build on linux.
With build 2003011508 linux, I get an error when clicking on the button at the
given URL. The alert reads: Error establishing an encrypted connection to
telebank1.ubs.com. Error Code: -8173. I don't see that problem with Konqueror.
Could this be the same bug but now caught earlier? Or is this a totally
different thing. The error message isn't very helpful.
Arthur, I can see the same thing with the build you mentioned. But this is new.
Please open a new bug and mark it dependent on this one, thanks.
Arthur, I've just checked out my nightlies. The problem about not being able to
load the https page started with the 2003010708 build. 2003010610 was still
working. I've checked tinderbox
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=01%2F06%2F2003+10%3A00&maxdate=01%2F07%2F2003+08%3A00&cvsroot=%2Fcvsroot
and it appears that two huge checkins from kaie@netscape.com made at 14:23 and
16:58 and dealing with SSL are most probably guilty for that.

Also, I've just noticed that there's a checkin from ssu@netscape.com
http://bonsai.mozilla.org/cvsquery.cgi?module=MozillaTinderboxAll&date=explicit&mindate=1043340000&maxdate=1043360000
that was made today and fixes bug 190247 and bug 190151 and also deals with SSH.
Maybe this checkin also corrects the problem we are seing here? Let's wait for
the next nightly and then we'll know.
there was a mozilla test build done with the patch from bug 190247.  I believe
you can find it here: ftp://ftp.mozilla.org/pub/mozilla/nightly/2003-01-23-08-trunk
Regressing banks is bad. We should try to get this resolved or at least
understood before 1.3beta ships next week.
Flags: blocking1.3b? → blocking1.3b+
i didn't checked this bug anymore, since it didn't looked like mine. John can
you look at this please? also see if Darin has some info since he did some work
on it. maybe is not form sub at all but i didn't wanted to take it out of the
our box yet since i'm not sure. 

BTW: can any of our great contributors find out the time frame of the regression
please? that would help to localize it. thx a lot!
Assignee: alexsavulov → jkeiser
Arthur, Sean,

I still get the same error message "Error establishing an encrypted connection to
telebank1.ubs.com. Error Code: -8173" with the latest nightly (2003012711) I
keep it with this bug because I think that maybe next to forms and cookies, our
problem could be something with SSH.
Erich: That error message is a PSM error. You you please disable OSCP in
edit\preferences\Privacy...\Validation ?

Matti, OCSP Validation _is_ disabled here.
Still there with 2003012722 linux, OSCP disabled. I'm very busy at the moment
and don't have time to track the bug down to a checkin. Sorry.
This is deeply investigated by Nelson Bolyard in bug 188856 thus I am markin
this bug as duplicate.


*** This bug has been marked as a duplicate of 188856 ***
Status: NEW → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → DUPLICATE
Tom Mraz, you're right, our comments #69 to #71 and #75 to #78 are about the
problem investigated in bug 188856. However, the initial bug which was there
before the problem of the error code -8173 is totally another bug. Therefore I'm
marking this one dependent of bug 188856, but it's not a dupe.
Status: RESOLVED → REOPENED
Depends on: 188856
Resolution: DUPLICATE → ---
Just tested with WinXP and trunk build 2003012709 and got the same error as
mentioned in Comment #75.

Changing OS to ALL.
OS: Linux → All
This morning I have checked in a patch that disables the DHE ciphers that are
said to cause this problem.

My checkin was very close before the tree closed, at about 7:30 pacific time
this morning. Maybe the build you have downloaded was created from sources
fetched at 4 a.m.. I think there is another round of builds getting kicked off
at 8 a.m.. I suggest to retest with builds that show up later today.

DHE ciphers has now been backed out. This bug can be worked on again. Make sure
you follow the steps described in comment #0 and check the first attachment
(image) in order to see what it should look like (left side of the image) vs.
what it probalby looks like (right side of the image)
Changing status back to FIXED as the new regression was completely different bug.
Also removing the dependence.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
No longer depends on: 188856
Resolution: --- → FIXED
Sorry, this bug (the original, from the reporter) is still here (linux
2003013005). Reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Just tested with WinXp and Trunk build 2003012904, and it isn't working in that
build either.
Question, is this patch ready to go in (with an "a" of course)?
Attachment #107182 - Attachment is obsolete: true
when I select "Orange/Blue payment slip" (comment 0, step 6), I get the message:
"You have no authorized account for this service."

> Question, is this patch ready to go in (with an "a" of course)?

the patch here has already been checked in...
Adding "or SSL problems" to the Summary. I don't know if the reason is SSL, but
it could be, since Forms and Cookies people didn't find anything. Over to NSS,
please check this out, it's a blocking 1.3b+. Thanks
Component: Form Submission → Libraries
Product: Browser → NSS
Summary: UBS E-Banking broken because of regression in processing forms and cookies → UBS E-Banking broken because of regression in processing forms and cookies or SSL problems
Target Milestone: mozilla1.3alpha → ---
Version: Trunk → 3.0
nelsonb@netscape.com, can you please have a look at this one?
this bug is a result of bug 171924.  the form on the page in step 8 has no
action attribute

==> Form submission
Assignee: jkeiser → form-submission
Status: REOPENED → NEW
Component: Libraries → Form Submission
Product: NSS → Browser
Version: 3.0 → Trunk
reassign back to jkeiser
Assignee: form-submission → jkeiser
Re: Comment #91 From Andrew Schultz

Wow, that's awesome. Thanks for pointing this out. Changing the summary accordingly.
Summary: UBS E-Banking broken because of regression in processing forms and cookies or SSL problems → UBS E-Banking broken because of regression in processing forms (no action attribute)
Um... Bug 171924 made our behavior compatible with IE, as I understand it.  Is
that not the case?

Oh, and I get a page that says "You have no authorized account for this
service." after step 6 from comment 0.... So I can't tell whether there is an
action attribute and whether there is a base href on that page.
Boris, I've seen that behavior now and then. Usually, starting all over would
work. But I'm going to post that code for you, as an attachment.
Boris, this is the form we are talking about. And I noticed that now there's an
additional step needed in comment #0: Before step 3, if you get a notice
saying: "Activating the latest UBS e-banking security solution." with a blue
"OK"-button at the end, first clik on that button and then only perform step 3.
As far as I could experience that, if you don't say OK, you won't have any
account to choose from and you'll get that error message you mentioned in
Comment #94.
Ok, I got it to work this time.  Indeed, there is a <base> there...

So see bug 171924 comment 12.  Since I once again have no IE on hand, someone
needs to test things a little here..... Did I mess up when I tested IE?  Does IE
behave differently here for http vs https?
With IE 6.0SP1 running on WinXP-SP1, the UBS site works fine. Now for the other
tests that bz mentioned.

Note: they appear to be working towards a site overhaul on Feb 15/16.
As for Bug #171924, the two test cases work the same for Mozilla
2003013104-TRUNK and IE 6.0SP1, that is, I get Bugzilla complaining about an
invalid attachment ID.

Oh, and that's HTTP only.

One other thing to test..... The form on the UBS site has:

<form method="post" target="_self">

and I wonder whether adding those attributes to the <form> tag may change the IE
behavior...
OK, I pulled the HTML files off Bugzilla and put them on my web space.

With that change, both IE and Mozilla work perfectly with the Original and
Modified test cases from Bug #171924. Weird.

Adding the HTML from Comment #100 got me 405 (POST not allowed) errors on both
IE and Mozilla. It's been a long time since I've played with forms on HTML, but
I'm sure I'm missing something.
David, what's important is not the page you get back (that will be bogus) but
what url you get taken to.  If the files are on your local site, do you stay on
the local site or are you taken to www.mozilla.org?
OK, I double-checked, and I always end up where I started from. Even when Base
is set to something totally different from where I opened the HTML.

FWIW, I get the 405 error when reading from a remote web server, but when
opening the HTML from my local disk, I don't get the 405 after clicking the button.
OK.. so could someone test with IE on an https server?  Or maybe inside a frame?
 Or both?

Basically, I would like to know why this site works in IE and fails in Mozilla
if the two behave identically.  ;)  If they do not, it would be nice to know
where the differences lie....  Does IE get the same HTML on that site?  Same JS?
jumping in here and I can't claim to have read all the previous comments
thoroughly, but...

following steps 1-7 in the original report in IE, and then doing a view source
on the orange payment slip, I get this:

<FORM NAME="PaymentSlipForm" 
ACTION="https://telebank1.ubs.com/classic/796e620f3e26323a312b2c700f3e26323a312b2c1d332a3a0c33362f0f38796d626e6a6c6767696d686b006e69/"
METHOD=POST TARGET="_self" OnSubmit="return isiwebJavaScriptCheck()" >

same actions in a phoenix nightly from a few days ago, and I see the form tag
with no action attrib.  forgive me if that's got no bearing on the current
discussion here... I'm happy to do more IE testing as required.
OK, to add more info.

Mozilla (latest nightly) gives :-
<form NAME="PaymentSlipForm"  METHOD=POST TARGET="_self" OnSubmit="return
isiwebJavaScriptCheck()" >

Netscape v4.8 gives :-
<FORM NAME="options"  METHOD=POST   TARGET="_self"  OnSubmit="return
isiwebJavaScriptCheck()" >

Opera 7.0 dies on starting the demo.

IE is as reported for v6.0


So, things are being customised based on browser detected.
Sounds like this site was depending on a bug in Mozilla... and then we fixed
that bug.
I don't think we're going to hold beta for this since it sounds like it's not
our bug.
Flags: blocking1.3b+ → blocking1.3b-
Asa: I agree. This bug will probably end up as Tech Evang IMHO. 
*** Bug 192234 has been marked as a duplicate of this bug. ***
I'm suffering from the same problem, can't make payments with UBS e-banking website.

I discussed this problem with the UBS e-banking helpdesk (before I notices the
bug report here), and they replied that they officially don't support Mozilla. 
After I read the bug report, I asked the helpdesk to point the developers to
this page since the fix is probably very rather easy.  No reply since...

Is Tech Evang going to look into this?


If you talk to them about this again, please point out that by "not supporting
Mozilla", what they are actually doing is supporting only a few proprietary
standards-non-compliant browsers instead of the many standards-compliant
browsers, a very bad thing.
Thought the best way of convincing them was pointing out the relationship
between Mozilla and the newer versions of Netscape... since they do support
Netscape.
Based on the info in this bug, it sounds like the page might work if they just
stopped trying to deliver different pages to Mozilla (perhaps they are lumping
in Mozilla/NS7 with NS4).  The page delivered to IE seemed to work in Mozilla.

==> Evang
Assignee: jkeiser → nitot
Component: Form Submission → Europe: West
Product: Browser → Tech Evangelism
QA Contact: vladimire → brantgurganus2001
Version: Trunk → unspecified
Severity: critical → major
Summary: UBS E-Banking broken because of regression in processing forms (no action attribute) → ubs.com - E-Banking broken because of regression in processing forms (no action attribute)
-->doron
Assignee: nitot → doron
As I am hurt by this bug (I am an UBS customer), I sent them an feedback message
to their customer support today, refering to the missing action="..." part of
the <form> tag in mozilla (as in contrast to IE).

I'll keep you updated if/when they react.
Dear all,

I received the following reaction from UBS today.  In short: they know the
problem/solution, and in one of the next releases they'll fix it.

Cheers,
Chris.

----

Your e-Mail from the 14.04.2003 has been forwarded to me. You've reported a
bug on our website in combination with Mozilla. According to your e-Mail,
our helpdesk told you, that we don't support Mozilla. Please excuse that
information, it's simply wrong.

We do support Mozilla, but only certain versions. At the moment the highest
version, that we support is 1.2.1. With the information on your e-Mail I
couldn't figure out which version you're using, I assume 1.3.

If that's the case, we're aware of the behaviour you've reported. The error
only occures in combination with Mozilla 1.3. We've already located the
mistake on our pages and it will be changed in one of the upcoming
e-Banking releases.

As soon as the version 1.3 is supported you'll find it on our browser list
http://www.ubs.ch/e/ebanking/classic/prerequisites.html

In the meantime I ask you to use either Mozilla 1.2.1 or Netscape 7.
Interesting answer from UBS. Although if taken literally, which seems to be what
they want you to do, this means they don't support Netscape 4.80, 7.01 or 7.02,
as the referanced web page only mentions Netscape 4.79 and 7.0.
Apparently the bug is fixed in the current version of the ubs e-banking website...
I don't see the problem from comment #0 with build 20030602. That makes two of
us, so I'm going to close this bug as WFM.
Status: NEW → RESOLVED
Closed: 22 years ago → 21 years ago
Resolution: --- → WORKSFORME
As of my understanding, it was a bug in the UBS software, not in Mozilla. I have
no nightly available, but I've tried to use the e-banking system with Mozilla
1.4b and Firebird 0.6. Both fail. So that doesn't look like resolved to me. With
both browsers, I still can experience the exact same behavior like described in
comment #0
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Changing URL (previous one returns 404), Click on Demo button to load demo.

The link in comment #117 is invalid now too, please use this instead:
http://www.ubs.com/e/ebanking/internet/requirements.html

As of today, they list the supported browsers as follow:

Internet browser:  Netscape 4.78, 7.0
                   Internet Explorer 5.5 SP2, 6.0 SP1, 5.1.6 (Mac
                   OS 9.2), 5.2.2 (Mac OS X)
                   Mozilla 1.21 (English)

So it's definitely not fixed yet.
URL: http://www.ubs.com/g/ebanking/classic... → https://telebank1.ubs.com/classic/en/...
With newly supplied URL's and a trunk build from a few hours ago, I can
duplicate the problem. So I agree with the reopening.
german. i can reproduce the "verify payment" problem in 1.4 from 2003 06 13. Has
anyone reported this problem to the bank? They seem to have a site that supports
us overall. Is this a problem in the real version instead of just the demo?
Assignee: doron → german
Status: REOPENED → NEW
Component: Europe: West → German
QA Contact: brantgurganus2001 → german
*** Bug 212313 has been marked as a duplicate of this bug. ***
*** Bug 212313 has been marked as a duplicate of this bug. ***
Hi,

For me the ubs e-banking seems to work correctly with mozilla after the upgrade
they did during last weekend.  Could somebody verify this?  (being careful since
it worked for me before, and then later on it stopped working again for some
reason).

So, hopefully this bug can be closed...

Chris.
No luck for me here, UBS did not fix the problem with this update. Bug has to
remain open.
It works for me now (mozilla 1.4b). It used to not work for me earlier. I cannot
reproduce the bug anymore...
Sebastian, Thanks!
Status: NEW → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → FIXED
-v
Status: RESOLVED → VERIFIED
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: