886720 - Passwords autofill on pageload broken in Firefox nightly

Status: RESOLVED DUPLICATE of bug 888972

(Toolkit :: Password Manager, defect)

Description

[Phoenix]

No corresponding errors in Errors Console.

Comment 1

[u331436]

Confirming with the 2.21.a1 nightlies (20130620 and 20130621). 
I will also check with 2.22a1 as well.

Comment 2

[Phoenix]

Reproduced in FF nightly with existing profile -> suspecting Toolkit issue
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20130625 Firefox/25.0

Comment 3

[Matthew N. [:MattN]]

Could you provide steps to reproduce?

Comment 4

[Phoenix]

1) Visit page for which you have password saved, for example, https://accounts.google.com
2) Enter login/account name/etc (suggestions works fine)
Expected results:
Password field filled automatically
Actual results:
Password field stays empty

Comment 5

[therube]

STR:
 
 
Start with an older browser version, FF 21.0 should work.

URL:  http://forums.mozillazine.org/ucp.php?mode=login
Enter your username: & password:
Click Login

You are prompted to save your login information.
Do so.

Log out.
 
 
Go back to, URL: http://forums.mozillazine.org/ucp.php?mode=login

Your username & password are pre-filled in.
Click Login

You are now logged in.

Logout.
 
 
Open a current FF Aurora or Nightly.

Go back to, URL: http://forums.mozillazine.org/ucp.php?mode=login

The username: & password: fields are no longer pre-filled in.
 
 
(Current Aurora, Nightly will not even prompt you to save your password had you initially started with that instead of an older version.)

Comment 7

[Frank Wein [:mcsmurf]]

Note that you duped a general Toolkit bug to a SeaMonkey bug. Is there a bug open for Firefox?

Comment 8

[Frank Wein [:mcsmurf]]

Reopening, this seems to be an issue in Firefox, too (I tested it on bugzilla.mozilla.org). Moving to Firefox product then as SeaMonkey seems to solve a different(?) bug.

Comment 9

[Frank Wein [:mcsmurf]]

Regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8ea92aeab783&tochange=7ba8c86f1a56 maybe it's also a regression from Bug 839961

Justin: Can you check if your work from Bug 839961 might be related here? Ignore the SeMonkey comments in the bug for now ;), this bug is now about passwords autofill broken in Firefox nightly builds. See Comment 4 and Comment 5 for steps to reproduce. I also checked with a nightly build that password autofill does not work anymore on bugzilla.mozilla.org. What does work though is entering the user name (so for example "[e-mail]") and after that it will automatically prefill the password. But in older nightly builds it autofilled username and password after page load (so no user action was needed for that). Or is this change of behaviour intentional?

Comment 10

[Frank Wein [:mcsmurf]]

Justin: Can you read Comment 9, this bug here might be a regression from your patch in Bug 839961 (not quite sure though).

Comment 11

[Matthew N. [:MattN]]

(In reply to Frank Wein [:mcsmurf] from comment #10)
> Justin: Can you read Comment 9, this bug here might be a regression from
> your patch in Bug 839961 (not quite sure though).

I also suspect that bug 839961 is the issue. The problem isn't reproducible reliably for me but I was able to reproduce sometimes.  

Can you set the pref signon.debug to true and screenshot the output from the browser console (turn off network and CSS errors) while loading a login page in safe mode?

Comment 12

[Frank Wein [:mcsmurf]]

Attachment: Output from Browser Console with an affected build (safe mode)

This is the requested info from Comment 11

Comment 13

[Frank Wein [:mcsmurf]]

Attachment: Output from Browser Console with a 2013-06-20 nightly build (no bug, safe mode)

Comment 14

[Frank Wein [:mcsmurf]]

Attachment: Output from Browser Console with an affected build (safe mode)

Sorry, made a mistake when creating the logs.

Comment 15

[Frank Wein [:mcsmurf]]

Attachment: Output from Browser Console with a 2013-06-20 nightly build (no bug, safe mode)

Comment 16

[Justin Dolske [:Dolske]]

"Login Manager (content): Password not filled. None of the stored logins match the username already present."

Some quick debugging (for the site used in the logs, bugzilla.mozilla.org) indicates that this is working as expected. When the code in _fillForm() runs, it has my test login with a username of "testing@test", and finds that the username field is already filled with "email address". (That's the text Bugzilla puts there by default.)

Please file a bug against Bugzilla to switch to using the placeholder attribute (https://developer.mozilla.org/en-US/docs/Web/HTML/Forms_in_HTML#The_placeholder_attribute), which is the proper way to do this.

The only question here is why this ever worked on Bugzilla in the first place. There's script right below Bugzilla's password field that seems to be fiddling with this prefilled string from a 200ms setTimeout, so I'd guess that's why it (sometimes?) worked before, and sometimes fails now.

Comment 17

[Frank Wein [:mcsmurf]]

Ok, I'll file a bug,
Just fyi: I can't reproduce the accounts.google.com/mail.google.com issue mentioned in another comment. So I guess this bug here can probably be closed as invalid (except if Phoenix comments that he can reproduce the Google issue with Firefox nightly).

Comment 18

[Matthew N. [:MattN]]

I could reproduce it intermittently with the mozillazine page from comment 5. I didn't look to see if there is script involved there though.

Comment 19

[Philip Chee]

Oops sorry Frank.

Comment 20

[Phoenix]

(In reply to Frank Wein [:mcsmurf] from comment #17)
> Ok, I'll file a bug,
> Just fyi: I can't reproduce the accounts.google.com/mail.google.com issue
> mentioned in another comment. So I guess this bug here can probably be
> closed as invalid (except if Phoenix comments that he can reproduce the
> Google issue with Firefox nightly).
Have no problems reproducing it on Nightly. Set signon.debug to true, make some tests
1) Open new tab, go to https://accounts.google.com/ServiceLoginAuth, enter login -> no password autofilled, no any messages in web console
2) Open new tab, press proposed picasaweb window which redirected me to https://accounts.google.com/ServiceLogin?hl=ru&continue=https%3A%2F%2Fpicasaweb.google.com%2Flh%2Flogin%3Fcontinue%3Dhttps%253A%252F%252Fpicasaweb.google.com%252Fhome&service=lh2&ltmpl=gp&passive=true -> both login and password filled
3) Close browser having opened https://accounts.google.com/ServiceLoginAuth tab from experiment 1), open browser again -> tab loaded with both login and password filled, open new tab, enter same address -> no autofill

Comment 21

[Frank Wein [:mcsmurf]]

Attachment: Output with STP from Comment 20 in Browser Console with an affected build

Ok, so I see what you mean in Comment 20. But: I cannot reproduce this every time, actually it's rather difficult to reproduce. Maybe should open a new bug not make sure things do not get mixed up here.

Comment 22

[Frank Wein [:mcsmurf]]

Attachment: Screenshot from STP in Comment 20

So just to make sure people know what the log is about: This is how it looks like. The page in the background was loaded with session restore, the page in the foreground was opened by me in a new tab (I just moved the second tab to a new window to make the screenshot). As you see, no password was autofilled. When opening the same address in a third, forth, ... tab, password autofill worked fine.
Phoenix: Can you open a new bug for that issue? Just to make sure things don't get mixed up. You can reference my log and my screenshot from this bug here.

Comment 23

[Frank Wein [:mcsmurf]]

Comment on attachment 767913 [details]
Output with STP from Comment 20 in Browser Console with an affected build

That log is actually wrong in some way, the "Login Manager" and "PwMgr mozStorage" entries in the log are from the first tab from Session Restore! It looks like for the second tab, there are no "Login Manager" and "PwMgr mozStorage" entries at all in the log.

Comment 24

[Justin Dolske [:Dolske]]

I can't reproduce either the Google or the Mozillazine issue. Both always fill the login for me.

Comment 25

[Phoenix]

Disabled add-ons, get password filled on accounts.google.com (o_O), opened picasaweb.google.com, get redirect on accounts.google.com -> both login/password not filled (-_-)

Comment 26

[Philip Chee]

WAG: Frank can you change the event listeners here:
https://hg.mozilla.org/mozilla-central/rev/58d5552a5ef4#l1.35
to capturing. See if this improves the problem.

Comment 27

[Alice0775 White]

(In reply to Justin Dolske [:Dolske] from comment #24)
> I can't reproduce either the Google or the Mozillazine issue. Both always
> fill the login for me.

Me too, it works as expected in Aurora24.0a and Nightly25.0a1.

(In reply to Phoenix from comment #25)
> Disabled add-ons, get password filled on accounts.google.com (o_O), opened
> picasaweb.google.com, get redirect on accounts.google.com -> both
> login/password not filled (-_-)

Works for me...

Comment 28

[Justin Dolske [:Dolske]]

Ok, I managed to reproduce this -- after many attempts -- with picasaweb.google.com (which redirects, but I don't know if that's important).

The listener in browser/base/content/content.js isn't even being called. I had a dump() there, among other logging, and when the failure happens nothing at all is output.

So this seems like a frame script problem. :(

Comment 29

[Alice0775 White]

if you stored plural accounts and passwords for the same site, autofill-filling account/password does not work. ANd I think this behavior is as expected.

Comment 30

[Alice0775 White]

(In reply to Alice0775 White from comment #29)
> if you stored plural accounts and passwords for the same site,
> autofill-filling account/password does not work. ANd I think this behavior
> is as expected.

s/autofill-filling/pre-autofill-filling/

Comment 31

[Frank Wein [:mcsmurf]]

Just for reference: I filed Bug 888731 on Bugzilla regarding the gray placeholder text in the login form.

Comment 32

[Justin Dolske [:Dolske]]

Attachment: Attempt to reproduce via test

I tried writing a test to make reproducing this easier -- a browser-mochitest that opens a Google login tab and checks for the expected filled login. I ran this a few times with |mach mochitest-browser toolkit/components/passwordmgr/test/browser_weirdbug.js  --run-until-failure --repeat 150|, but couldn't get any failures. Debug, opt, and a few other test variations.

I see bug 888972 just got filed, which seems to pin this failure on another bug? Can anyone reproduce after flipping the pref mentioned in bug 888972?

Comment 33

[Justin Dolske [:Dolske]]

Also, felipe mentioned that it might be interesting to see if DOMWindowCreated fares any better. He also noticed a possibly-related change to some B2G which seems to have run into the same problem... http://hg.mozilla.org/mozilla-central/rev/96af92fa87fd

Comment 34

[:Gavin Sharp [email: [e-mail]]]

(In reply to Justin Dolske [:Dolske] from comment #33)
> Also, felipe mentioned that it might be interesting to see if
> DOMWindowCreated fares any better. He also noticed a possibly-related change
> to some B2G which seems to have run into the same problem...
> http://hg.mozilla.org/mozilla-central/rev/96af92fa87fd

The use case there was stubbing out a Web API, and people relying on it being stubbed out prior to DOMContentLoaded (which fires after script can run). That doesn't seem relevant to this bug (which is about whether DOMContentLoaded fires, rather than when), AIUI.

Comment 35

[bhavana bajaj [:bajaj]]

Can QA please confirm if Fx23 is affected by trying the testcase in comment 32 ?

Comment 36

[bhavana bajaj [:bajaj]]

(In reply to Justin Dolske [:Dolske] from comment #32)
> Created attachment 769749 [details] [diff] [review]
> Attempt to reproduce via test
> 
> I tried writing a test to make reproducing this easier -- a
> browser-mochitest that opens a Google login tab and checks for the expected
> filled login. I ran this a few times with |mach mochitest-browser
> toolkit/components/passwordmgr/test/browser_weirdbug.js  --run-until-failure
> --repeat 150|, but couldn't get any failures. Debug, opt, and a few other
> test variations.
> 
> I see bug 888972 just got filed, which seems to pin this failure on another
> bug? Can anyone reproduce after flipping the pref mentioned in bug 888972?

:Dolske passing this on to you due to the suspected regressing bug here, please reassign as needed.

Comment 37

[Frank Wein [:mcsmurf]]

therube: Can you check your mozillazine issue from Comment 5 with the pref 
browser.newtab.preload set to false? If the issue does not happen anymore, then we forwar-dupe this bug here to Bug 888972 as all issues are handled then.

Comment 38

[therube]

> browser.newtab.preload

Pref did not exit by default, so I had to add it; Boolean, false.

Doing so, then restarting, had no affect.
I still see the issue, un/pw not autofilling - in SeaMonkey.
 
 
Just to note, I have never been able to confirm this in FF (& still can't).
Was just relying on the fact that Phoenix was able to.
And then others commented that they too were able to dup, so I just left it at that.
 
 
Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Firefox/24.0 SeaMonkey/2.21a2
Build identifier: 20130710013001

Comment 39

[[e-mail]]

(In reply to therube from comment #38)
> I still see the issue, un/pw not autofilling - in SeaMonkey.
SeaMonkey is still waiting for bug 886990 in order to catch up with bug 839961, at which point it may or may not then also suffer from this bug.

Comment 40

[Frank Wein [:mcsmurf]]

Forward-duping this bug here to Bug 888972 then as most of this bug here was about Firefox.

Comment 41

[bhavana bajaj [:bajaj]]

(In reply to therube from comment #5)
> STR:
>  
>  
> Start with an older browser version, FF 21.0 should work.
> 
> URL:  http://forums.mozillazine.org/ucp.php?mode=login
> Enter your username: & password:
> Click Login
> 
> You are prompted to save your login information.
> Do so.
> 
> Log out.
>  
>  
> Go back to, URL: http://forums.mozillazine.org/ucp.php?mode=login
> 
> Your username & password are pre-filled in.
> Click Login
> 
> You are now logged in.
> 
> Logout.
>  
>  
> Open a current FF Aurora or Nightly.
> 
> Go back to, URL: http://forums.mozillazine.org/ucp.php?mode=login
> 
> The username: & password: fields are no longer pre-filled in.
>  
>  
> (Current Aurora, Nightly will not even prompt you to save your password had
> you initially started with that instead of an older version.)

Can you please help verify if the issue is fixed for you now on aurora and beta given the DUP of this bug (888972) is now resolved .

Comment 42

[u279076]

Flagging for verification to see if QA is successful. If not, please set need-info to therube.

Comment 43

[Manuela Muntean [Away]]

Verified as fixed with latest Aurora and 25 beta 2 (build ID: 20130923194050), on: Ubuntu 12.10 32-bit, Win 7 64-bit and Mac OS X 10.8.4, following the STR from comment 20.