156790 - secu.org - Unable to submit secure webpage form data

Status: RESOLVED INVALID

(Web Compatibility :: Site Reports, defect, P2)

Description

[Brian Craft]

Any nightly builds of Mozilla in Linux since build 2002052918 will not send the
data on the above URL.  Build 2002052918 works fine.  This is my bank login website.

Comment 1

[Alexandru Savulov]

PSM issue maybe? (personal security manager) Is not a default on linux like on
other platforms.

Comment 2

[Vladimir Ermakov]

Confirming on build 2002-07-02-04-trunk. On windows 98 I am redirected to a page
saying that my login is invalid, and on linux it only changes the text in the
Account# text field to "Loading"

Comment 3

[Brian Craft]

 Yes this is exactly what's happening......"on linux it only changes the text in
the Account# text field to "Loading".  

Thanks,
Brian Craft
[e-mail]

Comment 4

[Vladimir Ermakov]

Attachment: testcase

I am very confused how this works at all on IE and on Windows branch, but on
both windows and linux trunk builds the form is not submited. The problem here
seems to be that in one case the javascript submit() function calls the
onsubmit handler and in the other it does not... When it does call the onsubmit
the handler returns false (There is actually no way for it to return true!!!)
so the form submission is canceled. When it does not call the event handler,
the form is submitted and the request is processed like it should. I dont know
what is the right behaviour, but I think I've seen this bug somewhere, I'll
look for it.

Comment 5

[Boris Zbarsky [:bzbarsky]]

vladimir, are you seeing that testcase act differently on Windows and Linux?  
Or just the original page?

Note that this behavior will be different between quirks and standards mode.

Comment 6

[Vladimir Ermakov]

On windows branch it is "passing" and on windows trunk it is failing just like
on linux trunk.

Comment 7

[Vladimir Ermakov]

That dupe was bug 45190, its actually reverse of this. It was a bug I filed, but
it was marked invalid for backward compatibility, and compatibility with IE.
Based on that resolution the behaviour experienced in the trunk builds is a bug.

The javascript submit() method should not run the onsubmit event handler for the
form.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Vladimir, the decision of bug 45190 was reversed in strict mode only (see bug
144534).  Your testcase is in strict mode.

*** This bug has been marked as a duplicate of 155453 ***

Comment 9

[Vladimir Ermakov]

oh, cool, that explains it.

Comment 10

[Vladimir Ermakov]

This should be evengelised to the bank...

Comment 11

[Vladimir Ermakov]

moving to evangelism

Comment 12

[Boris Zbarsky [:bzbarsky]]

to banks owner.

Comment 13

[Jon Levell]

This has started to happen to me with my bank:
https://online.lloydstsb.co.uk/customer.ibc
I presume it's the same bug? Can someone confirm it for me?
Either way it doesn't as of build 2002071722 on linux
and it's going to be a real pain if I have to wait for 
them to fix their web page. Hmph. 

Comment 14

[Jon Levell]

Ignore the above comment, the LloydsTSB site works again with later builds (see
bug 155453 comments 18-23.

Comment 15

[Nick Bebout]

SPAM: New Components

Comment 16

[chris hofmann]

one of the best references/recommendations I've found for encouraging financial institutions to support firefox is located at bankers on-line web site 

http://www.bankersonline.com/security/security_browserthreat070204.html 

It was written in 2004 during the download.ject attack, but much of it still applies today.  This is a good link to send when contacting banks.

Comment 17

[Karl Dubost💡 :karlcow]

→ ping webpb.secu.org
PING webpb.secu.org (205.178.189.131): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5