Closed Bug 998893 Opened 10 years ago Closed 9 years ago

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

Categories

(Toolkit :: Password Manager, defect)

29 Branch
defect
Not set
normal
Points:
5

Tracking

()

RESOLVED FIXED
mozilla40
Iteration:
40.3 - 11 May
Tracking Status
firefox40 --- fixed

People

(Reporter: Chris, Assigned: MattN)

References

()

Details

Attachments

(1 file, 1 obsolete file)

39 bytes, text/x-review-board-request
mak
: review+
Details
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.
Component: Untriaged → Password Manager
Product: Firefox → Toolkit
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: firefox-backlog?
OS: Linux → All
Hardware: x86_64 → All
Summary: Login/password not auto-filled on some websites → Login/password not autocompleted due to custom placeholder implementation swapping @value
Flags: firefox-backlog? → firefox-backlog+
This also affects vBulletin sites such as http://www.zyngaplayerforums.com/
Assignee: nobody → MattN+bmo
Status: NEW → ASSIGNED
Iteration: --- → 40.1 - 13 Apr
Points: --- → 5
Flags: qe-verify?
Iteration: 40.1 - 13 Apr → 40.2 - 27 Apr
Iteration: 40.2 - 27 Apr → 40.3 - 11 May
Attached file MozReview Request: bz://998893/MattN (obsolete) —
/r/7971 - Bug 998893 -

Pull down this commit:

hg pull -r 92f525a9092d044cfb0fc42339d7169cf4de091f https://reviewboard-hg.mozilla.org/gecko/
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 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 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/
Attachment #8600176 - Flags: review?(mak77)
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.
Flags: qe-verify? → qe-verify-
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.
Attachment #8600176 - Flags: review?(mak77) → review+
Flags: in-testsuite+
Whiteboard: [fixed-in-fx-team]
https://hg.mozilla.org/mozilla-central/rev/651329fc467a
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → mozilla40
Attachment #8600176 - Attachment is obsolete: true
Attachment #8618136 - Flags: review+
You need to log in before you can comment on or make changes to this bug.