998893 - Login/password not autocompleted due to custom placeholder implementation swapping @value

Status: RESOLVED FIXED

(Toolkit :: Password Manager, defect)

Description

[Chris Vanden Berghe]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release)
Build ID: 20140410213654

Steps to reproduce:

I have stored login/password (txtemail/txtpassword) for Easyroommate (http://www.easyroommate.com.sg/) but login/passwords fields are not autofilled when visiting website. Viting the alternative login page (http://www.easyroommate.com.sg/login.aspx) does work as expected.


Actual results:

Both fields remain empty.


Expected results:

Both fields should be filled out.

Comment 1

[Matthew N. [:MattN]]

Hello, thanks for the report.

Logging from page load:

Login Manager (content): onFormPassword for http://www.easyroommate.com.sg/
Login Manager: Counting logins matching host: http://www.easyroommate.com.sg formSubmitURL:  httpRealm: null
PwMgr mozStorage: _countLogins: counted logins: 1
Login Manager: Searching for logins matching host: http://www.easyroommate.com.sg formSubmitURL: http://www.easyroommate.com.sg httpRealm: null
PwMgr mozStorage: _searchLogins: returning 1 logins
PwMgr cryptoSDR: SDR slot status is 5
PwMgr mozStorage: _findLogins: returning 1 logins
Login Manager (content): found 1 matching logins.
Login Manager (content): Password not filled. None of the stored logins match the username already present.
Login Manager (content): onFormPassword for http://www.easyroommate.com.sg/
Login Manager: Counting logins matching host: http://www.easyroommate.com.sg formSubmitURL:  httpRealm: null
PwMgr mozStorage: _countLogins: counted logins: 1
Login Manager: Searching for logins matching host: http://www.easyroommate.com.sg formSubmitURL: http://www.easyroommate.com.sg httpRealm: null
PwMgr mozStorage: _searchLogins: returning 1 logins
PwMgr cryptoSDR: SDR slot status is 5
PwMgr mozStorage: _findLogins: returning 1 logins
Login Manager (content): found 1 matching logins.
Login Manager (content): Password not filled. None of the stored logins match the username already present.

Logging from focusing and then hitting the down arrow on the keyboard:
Login Manager: AutoCompleteSearch invoked. Search is: Type email here
Login Manager: Creating new autocomplete search result.
Login Manager: Searching for logins matching host: http://www.easyroommate.com.sg formSubmitURL: http://www.easyroommate.com.sg httpRealm: null
PwMgr mozStorage: _searchLogins: returning 1 logins
PwMgr cryptoSDR: SDR slot status is 5
PwMgr mozStorage: _findLogins: returning 1 logins
Login Manager: 0 autocomplete logins avail.

Note the "Type email here" that we are searching for as the username. The problem is that this site is implementing its own placeholder effect instead of using the standard @placeholder attribute for this. We won't fix the auto-fill case because there isn't much we can do (overwriting the existing values causes other problems e.g. bug 270558). The website should be contacted to get them to use @placeholder when supported.

I'm morphing this bug to cover the autocompletion which we can possibly fix. We normally handle that fine in situations like this where auto-fill didn't work but in this case we somehow end up searching for the old @value (containing placeholder text) for some reason.

Comment 2

[Matthew N. [:MattN]]

This also affects vBulletin sites such as http://www.zyngaplayerforums.com/

Comment 3

[Matthew N. [:MattN]]

Attachment: MozReview Request: bz://998893/MattN

/r/7971 - Bug 998893 -

Pull down this commit:

hg pull -r 92f525a9092d044cfb0fc42339d7169cf4de091f https://reviewboard-hg.mozilla.org/gecko/

Comment 4

[Matthew N. [:MattN]]

Comment on attachment 8600176 [details]
MozReview Request: bz://998893/MattN

/r/7971 - Bug 998893 -

Pull down this commit:

hg pull -r 6befe196c402e05edd61e19ef2b329a16f8e0b1b https://reviewboard-hg.mozilla.org/gecko/

Comment 5

[Matthew N. [:MattN]]

Comment on attachment 8600176 [details]
MozReview Request: bz://998893/MattN

/r/7971 - Bug 998893 -

Pull down this commit:

hg pull -r ce56d5b35ba56da6fda1988efacf4ebfd9d65a3e https://reviewboard-hg.mozilla.org/gecko/

Comment 6

[Matthew N. [:MattN]]

Comment on attachment 8600176 [details]
MozReview Request: bz://998893/MattN

/r/7971 - Bug 998893 -

Pull down this commit:

hg pull -r ce56d5b35ba56da6fda1988efacf4ebfd9d65a3e https://reviewboard-hg.mozilla.org/gecko/

Comment 7

[Matthew N. [:MattN]]

Try push is green so requesting review: https://treeherder.mozilla.org/#/jobs?repo=try&revision=ce56d5b35ba5

I confirmed that this issue isn't specific to form history (aka. satchel) by testing with the <textbox type=autocomplete> from the homepage widget from about:preferences so that's why the fix is in autocomplete.

Comment 8

[Marco Bonardo [:mak]]

Comment on attachment 8600176 [details]
MozReview Request: bz://998893/MattN

https://reviewboard.mozilla.org/r/7969/#review6955

The fix looks safe-enough to try it.

::: toolkit/components/autocomplete/nsAutoCompleteController.cpp:473
(Diff revision 3)
> +          nsAutoString value;

Please add a comment explaining what case we are handling here, we have far too much obscure code here.

::: toolkit/content/tests/chrome/test_autocomplete_change_after_focus.html:50
(Diff revision 3)
> +      field.value = "New value";

please add an info("field focused"); so we can track eventual timeouts better.

Comment 9

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/651329fc467a

Comment 10

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/651329fc467a

Comment 12

[Matthew N. [:MattN]]

Attachment: MozReview Request: Bug 998893 -