Closed Bug 968324 Opened 12 years ago Closed 12 years ago

Auto fill User/PW fails when focus starts in Name field

Categories

(Toolkit :: Password Manager, defect)

Product:
Toolkit
Component:
Password Manager
Version:
29 Branch
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: rvjanc, Unassigned)

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release) Build ID: 20140204004003 Steps to reproduce: Went to a site(s) where the User/PW should auto fill after clicking in the User field. Actual results: Clicking on the User field which had initial focus failed to fill in User/PW. Needed to remove focus from the User field by clicking on the page; then, returned focus to the User field. Clicked in the User field and the User/PW filled in. Expected results: With initial focus in the User field click in the User field and the User/PW should fill in. I first noticed this in Nightly a few weeks ago and now see it in Aurora, FF29a2.
Works fine for me on gmail.com, nightly 30.0a1 (2014-02-10), win 7 x64. Please provide an URL that shows the problem.
Here is a a place where it doesn't work https://webmail.earthlink.net/wam/login.jsp Note that I have just determined a bit of added info. It doesn't work when you first need to type in the master PW. If you go to that link and the master PW has already been typed in it works. Didn't notice it before since that Webmail site is usually the first place I go.
The credentials are autofilled for me on nightly 30.0a1 (2014-02-11), Mac OS X 10.8.5, after opening https://webmail.earthlink.net/wam/login.jsp and entering then the master password when prompted. Please check if the issue occurs using Firefox in safe mode (with your addons disabled): http://support.mozilla.com/kb/Safe+Mode Or on a new, empty profile: http://support.mozilla.org/en-US/kb/Managing-profiles#w_starting-the-profile-manager
Component: Untriaged → Password Manager
Product: Firefox → Toolkit
Issue still there in safe-mode. Will check in a bit with blank profile.
Created blank profile. Turned on MPW. Went to test site and stored PW when asked. Quit Aurora. Relaunched Aurora from blank profile. Went to test site and after filling in MPW all was good. NOTE: that in my real profile I have three accounts on that site. Redid the test with a second account stored and NEEDED TO REMOVE FOCUS FROM THE USER FIELD BY CLICKING ON THE PAGE; then, returned focus to the User field. Clicked in the User field and the User/PW choices dropped down. Seems like the issue only occurs when there is more than one User. Don't know if this is worth chasing down. Your call.
I just checked this on FF28b1 and it has the same behavior, NEED TO MOVE FOCUS. The "normal" behavior occurs on FF27.0, DON'T NEED TO MOVE FOCUS. Seems like some type of regression in FF28b1.
Do you want to help further and find a regression range, if your time permits? We have a tool for that called mozregression, it's very simple to use. http://mozilla.github.io/mozregression/
I will give it a try. I assume because of the nature of this bug (i.e., need more than one log in and master PW), I need to use the tool with particular profile. Note that I have individual profiles for Nightly, Aurora, Beta and release that I use an Applescript when launching.
(In reply to RobertJ from comment #8) > I assume because of the nature of this bug (i.e., need > more than one log in and master PW), I need to use the tool with particular > profile. From what I understand, you just need to store 2 accounts in Firefox. You can do that on new profiles. Mozregression by default opens new profile for each downloaded build.
OK will give it a try. Since the current release is OK but the beta isn't, want to suggest a bad/good range to start me off.
(In reply to RobertJ from comment #10) > want to suggest a bad/good range to start me off. Let's take the latest nightly 27 as a good build: 2013-10-28. To be really sure about this, you can manually download the build and check is good ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013/10/2013-10-28-03-02-05-mozilla-central/ For the good build, you don't have to enter anything, and it will take the latest nightly So, you'll have in mozregression: mozregression --good=2013-10-28
This either will not work or take forever. After downloading/installing/launching the first nightly using the tool, it takes a bit of time to log into two accounts and save the PW's; then set a MPW. Then to test need to quit the nightly and relaunch; however, the previously entered info does not seem to be in any profile - can't find a profile from the initial launch. Not sure this tool is appropriate for this kind of bug. Since we know that the bug is not in the current release and it is in the current beta how about telling me how to translate those builds to nightly's, were to find them and I will go through them manually with a profile I set up with the accounts etc preloaded. One additional note, since it took me time to log into two accounts and save the PW's; then set a MPW; the terminal timed out.
(In reply to RobertJ from comment #12) > how about telling me how to translate those builds to > nightly's, were to find them and I will go through them manually with a > profile I set up with the accounts etc preloaded. Try to start with ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013/10/2013-10-28-03-02-05-mozilla-central/ - which should be good And then with ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013/12/2013-12-09-03-02-02-mozilla-central/ - which should be bad Then you continue by dividing to half the distance between builds. Here are the builds: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013 I suspect somewhere in the 11th month is your answer.
(In reply to Paul Silaghi, QA [:pauly] from comment #13) > (In reply to RobertJ from comment #12) > > how about telling me how to translate those builds to > > nightly's, were to find them and I will go through them manually with a > > profile I set up with the accounts etc preloaded. > Try to start with > ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013/10/2013-10-28-03- > 02-05-mozilla-central/ - which should be good > And then with > ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013/12/2013-12-09-03- > 02-02-mozilla-central/ - which should be bad - ACTUALLY IS GOOD, WILL PUSH TOWARD THE END OF 2013 FROM THERE
(In reply to RobertJ from comment #14) > ACTUALLY IS GOOD, WILL PUSH TOWARD THE END OF 2013 FROM THERE yes, go ahead
Last good nightly: 2013-12-17 First bad nightly: 2013-12-18 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b1e5ade62913&tochange=862cb6a1cc88 The culprit is on the list.
Quite a list.
I suspect bug 946549. Justin, could you please take a look?
Flags: needinfo?(dolske)
Debugging output would be helpful, see http://wiki.mozilla.org/Firefox:Password_Manager_Debugging But this sounds a lot like we're probably filling in the login at a slightly different time, but the site is clearing it. Not much we can do about that.
Flags: needinfo?(dolske)
This is not site specific. It happens on ALL SITES where I have multiple accounts and need to fill in the master PW before I can log in. I first need to remove focus from the User field and then return focus before the drop down with the User options appears.
This bug did not exist on nightly: 2013-12-17 It was introduced on nightly: 2013-12-18 The bug is not site specific. It exists on https://webmail.earthlink.net/wam/login.jsp https://wisconsin.aaa.com/ https://www.llbean.com/ https://www.express-scripts.com/ https://www.getipass.com/ipass/LoginPin.jsp https://www.mybank.com/Logon.aspx and others. It shows up on sites where a user has multiple accounts and the user uses a master PW. So the comment "Not much we can do about that." is in my view not the case. Now I do understand if it is a bug not worthy of being fixed; if that is the case just say so and close this by saying will not fix.
This bug no longer exists in Aurora (2014-03-13) and (2014-03-12); I have not checked any other versions.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.