966780 - Password not stored on http://vtp.audi.com due to click handler instead of submission handler

Status: NEW

(Core :: General, defect)

Description

[TheRave]

User Agent: Mozilla/5.0 (Windows NT 6.3; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release)
Build ID: 20140201074923

Steps to reproduce:

signon.overrideAutocomplete;true
signon.debug;true

Go to page:

http://vtp.audi.com/agwb/i/s/controller.do#/s
-> go to "Meine Suchaufträge"
-> go to "Bitte melden sie sich an"
-> New Div appears with logon & password field.
-> Enter login data & submit


Actual results:

After successful login there is no message from Fx regarding storage of the password.

Checked Options->saved passwords-> no values stored

Output from browser console:
Login Manager (content): onFormPassword for http://vtp.audi.com/agwb/controller.do?act=search&v=0&sid=0&embed=none#overlay/load/agwb/controller.do?act=searchagent&v=1&sid=1&paramtransfer=1&getParamSearch=1&sagentid=-1&sa_resultlist=-1&width=800&height=auto
Login Manager: Counting logins matching host: http://vtp.audi.com formSubmitURL:  httpRealm: null
PwMgr mozStorage: _countLogins: counted logins: 0
Login Manager (content): onUsernameInput from DOMAutoComplete
PwMgr cryptoSDR: SDR slot status is 5
Login Manager: Searching for logins matching host: http://vtp.audi.com formSubmitURL: http://vtp.audi.com httpRealm: null
PwMgr mozStorage: _searchLogins: returning 0 logins
PwMgr mozStorage: _findLogins: returning 0 logins
Login Manager (content): found 0 matching logins.

Comment 1

[Paul Silaghi, QA [:pauly]]

Confirmed in 30.0a1 (2014-03-13), Win 7 x64.

Comment 2

[Matthew N. [:MattN]]

This won't work in any browser since the page is using a click handler on the submit button instead of the normal behaviour of using a form submission listener to implement a login form with JS. No browser (with current data) can accurately detect such a case. The page should switch to a form submission to initiate login.

If you could contact the site and point them here then they should be able to fix this.

Thanks

Comment 3

[TheRave]

Looks like this are webdesign decisions for this kind of buttons. Always if i see these graphical buttons i expect already that the password manager runs into trouble. I will inform Audi company to look into this matter. But i doesnt think, that they will do something here. For me this is also no solution, because the next webpage, where the password manager not works is already waiting.

A possible solution could be that the user supports Fx to recognize such elements in a setup scenario for example a shortcut or context menu entry that opens a ui, where the user have to click to the fields & submit buttons. The Fx would store these values and on next time Fx knows what is to do on this URL.

Comment 4

[TheRave]

By the way, i disagree that this is a evangelism bug. It is not related to one specific webpage. It is related to webpages which are using the click handlers. Tendency -> rising

Comment 5

[Karl Dubost💡 :karlcow]

Not sure it's an evangelism bug either.

Comment 6

[Hallvord R. M. Steen [:hallvors]]

We probably need some "if a script has read an input type=password's value and does an XMLHttpRequest call, suggest saving the password" heuristics. I disagree that this is an evangelism issue.