Closed Bug 1026941 Opened 10 years ago Closed 10 years ago

Password manager unable to fill username and pass consistently at poczta.wp.pl

Categories

(Toolkit :: Password Manager, defect)

29 Branch
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: Noah, Unassigned)

References

()

Details

Someone's having trouble getting 

Much of the investigation was done in this thread:
https://support.mozilla.org/en-US/questions/1003647

We have password manager debug logs:
https://support.mozilla.org/en-US/questions/1003647#answer-585090
https://support.mozilla.org/en-US/questions/1003647#answer-585091

Login urls:
http://profil.wp.pl/
http://profil.wp.pl/login.html

I created a test webmail account at poczta.wp.pl:
user: firefox2014@wp.pl
pass: mozilla1

MattN, I was wondering if you could take a look at this and see if you can reproduce using the login details provided above with a master pass set. Thanks!

He's using a master password and the user's about:support info is here:
https://support.mozilla.org/en-US/questions/1003647#answer-588261

His most interesting comment:
"I have just noticed something interesting: When I restart FF and once it starts and while it's still loading other tabs if I quickly open the login page of the website in question before master password window shows up, then once I type in the master password and confirm it, login and password on the website appear filled in.. However if I open the login page beforehand and then restart FF, once it opens and I type in the master password, these details are not filled in.. I recorded a screen capture to illustrate the issue:

http://screencast.com/t/7vt2EdR8yH

Not sure if that gives any clue?"
* Someone's having trouble getting his login to autofill at http://profil.wp.pl/

MattN, got any thoughts on this?
Flags: needinfo?(MattN+bmo)
I thought dolske already explained the problem to you on IRC.

The site does $('#loginForm').attr('action', 'https://profil.wp.pl/login.html') while the default action is the same except http instead of https. Even worse is that the page focuses the username field in the line above that one. Focusing the username field is what triggers the MP dialog IIRC. the http action domain is queried from the password list while the password is stored with the HTTPS version since the action is HTTPS upon submission.

There are so many things wrong with this login page and it could fix them easily so I'm not sure how much we should care about this one site:
(a) The login page should be hosted on HTTPS (see console warning)
(b) The form action doesn't need to change at load time, it should always be HTTPS
(c) if (a) and (b) are too hard (they're not), move the $("#login").focus() call after the @action switching.
Flags: needinfo?(MattN+bmo)
Yes sorry about that. I was looking to see if you could expand on dolske's reply:
(6/2/2014 4:38:18 PM) dolske: Noah: his saved login is expecting to submit to https://, but the page is http:// when it loads. for some reason the page's submit url seems to change to https:// between loading and him triggering autocomplete.

Which you did. :) And thanks for the full explanation and fixes the site can implement. Very appreciated!

I had that person experiencing this problem send those site fix recommendations to the webmaster & translate them into Polish.

Luckily, we were able to use the Saved Password Editor addon to edit the problematic url to be https instead of http. (https://poczta.wp.pl rather than http://poczta.wp.pl) That fixed it and the username and password are now autofilled. See: https://support.mozilla.org/en-US/questions/1003647#answer-593010

The quirky behavior of the site must've caused him to save the wrong submit url. Resolving as WORKSFORME. Should've did that on 6/18 but better late than never. :)
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.