login form user/passwd not detected by logins

[Kris_88]

Currently I have around 490 passwords associated with websites

It's amazing.
Of course, I visit many sites, but registering on each one is incomprehensible to me. Just to login on each one for a month, you need to login on more than 10 different sites a day. And the next day - another 10 sites, etc. I can't imagine any activity or hobby that would require this. Perhaps it’s a hobby of “registering on sites.”

[cannonmc]

I've only just seen this thread and noticed no-one seemed to mention 'private browsing'.

In private browsing PM won't remember new passwords (old stored ones are fine).

So when I sign-in to a new site I come out of private browsing, sign-in to site, get 'Remember' box, click OK. Set back to private browsing. after a restart everything is fine.

Hope I'm not teaching granny to suck eggs.

[dapgo]

I don't have Firefox installed so can't compare the effectiveness of Pale Moon verses it, but registering on a new site around once a year sounds unusual to me.

Maybe not every few days, but easily once a week I will store a new site and password pair. Currently I have around 490 passwords associated with websites, and certainly with my online purchasing for the holiday season that number was boosted quite a bit recently. I think it is probably difficult to assume what is typical only based on one's own behaviour?

exactly, people managing part of their lives online are on a continuous need of creating accounts.
From the government, to shopping, to service contracts, and so on...

Today i have a problem with PM logins again, i go to login on a service where i have account and password saved, and PM offers a dropdown list with 9 emails/username for for the field "Username or Email".

As i don't know which can be the good one, I check login on PM and I realize that:

• PM login has URL https://accounts.domain.com

• whereas service url is https://login.domain.com

• and field names on PM login and field name on the page are the same id; "username" and "password"

The i select the good email from the list BUT nothing is populated on "password" field

Then
I modify the pM logins to fit the URL to https://login.domain.com
Reload the page
The dropdownlist offers email/usernames
I pick the good one
The password field is populated and the login in successful


Why the dropdown is offereing these 9 usernames? ( I have much more than 9 usernames in my logins)
Shouldn't they be ordered by match with the domain?

[dapgo]

feedback from other users, please

Have you ever seen a dropdown list containing usernames/emails that don't belong to the logins stored for an specific page?

[Moonchild]

Yes that can happen when you have nothing stored as it will fall back to standard form history in that case, which is not site-bound, to help you fill in data.

[dapgo]

Yes that can happen when you have nothing stored as it will fall back to standard form history in that case, which is not site-bound, to help you fill in data.

What about when you HAVE a login stored?
Because it happens in some page logins, then you go to stored logins and there is an entry for this domain.

I can start creating a list of site logins where it happens.
But i am really surprised if other users are not suffering the same case.

Because I saw the same lack of feedback before; regarding not recognized input fields; no other user confirmed the "behaviour/problem". But when i did complete with a new install/profile then behavior was then same and the "problem" global.

[Moonchild]

Are you sure the actual host/URL is the same stored in the password manager? because they are not stored "by domain" as that would not be granular enough. http/https matters, exact host name matters.

[dapgo]

real example Booking.com
URL: https://account.booking.com/sign-in?
PM and Firefox have several accounts stores in login and passwords,


In Firefox 115esr
login field (with cookies): shows a login name
login field (clean cookies/private): empty, type 1st char and a dropdown shows loginnames (different accounts)

In Palemoon 33.1
login field (with cookies): empty and not option
login field (clean cookies/private): empty and not options

from preferences, stored passwords, edit password, "Guess from" -> Not suitable login form...

pm_login.png

form:
login :id="loginname
form:<form class="nw-signin" novalidate="">
<input id="hidden-password" name="password" autocomplete="current-password" aria-hidden="true" focusable="false" tabindex="-1" type="password">
<input name="loginname" autocomplete="username" autocapitalize="off" autocorrect="off" spellcheck="false" data-focus="true" data-ga-action="start typing" data-ga-label="username" id="loginname" value="" type="text">

[Kris_88]

real example Booking.com

If you add field descriptions to the "recipes.json" file, PM will prompt you to save the password and autofill will work.

I checked 2 options, both work.
1)

Code: Select all

    {
      "description": "https://account.booking.com/sign-in",
      "hosts": ["account.booking.com"],
      "usernameSelector": "#username",
      "passwordSelector": "#hidden-password"
    }

2)

Code: Select all

    {
      "description": "https://account.booking.com/sign-in",
      "hosts": ["account.booking.com"],
      "usernameSelector": "input[name=username]",
      "passwordSelector": "input[name=password]"
    }

[Kris_88]

Regarding the problem on this link:
https://account.booking.com/sign-in

1) First, the user name (email) is entered and at the time of submitting the form, the password field is empty. Therefore the entire form is ignored.
_getFormFields:
https://repo.palemoon.org/MoonchildProd ... t.jsm#L755
_getPasswordFields:
https://repo.palemoon.org/MoonchildProd ... t.jsm#L682
https://repo.palemoon.org/MoonchildProd ... t.jsm#L694

I suggest replacing line

Code: Select all

pwFields = this._getPasswordFields(form, isSubmission);

with

Code: Select all

pwFields = this._getPasswordFields(form, false);

2) The username field is looked for before the password field, while on a form the username field is located after the password field. Therefore the username field will not be found.
_getFormFields:
https://repo.palemoon.org/MoonchildProd ... t.jsm#L767

I suggest replacing line

Code: Select all

for (var i = pwFields[0].index - 1; i >= 0; i--) {

with

Code: Select all

for (var i = 0; i < form.elements.length; i++) {

Both of these issues are not problems if the username and password fields are defined in the recipes.json file.
https://repo.palemoon.org/MoonchildProd ... t.jsm#L729

[dapgo]

thanks, good research
I suppose other browser have included in their code functions to process this "non standard" forms

It would be great to have an addon to simplify the process to add ids to recipes.json

[Kris_88]

I suppose other browser have included in their code functions to process this "non standard" forms

I looked at the source code of FF 127 and it seems to me that they did not invent anything fundamentally new.
In general, I have several ideas, but I need free time and the mood to implement them...

[Moonchild]

The second change makes sense but I'm not sure about the first. It's poorly documented what "isSubmission" actually indicates or what the resulting behaviour is when it's just set to "false"

EDIT: tracking in Issue #2537 (UXP)

[Kris_88]

The second change makes sense but I'm not sure about the first. It's poorly documented what "isSubmission" actually indicates or what the resulting behaviour is when it's just set to "false"

As far as I understand, the _getFormFields() function is used in two cases:
- when submitting a form, to prompt the user to save the entered credentials.
- when loading the page, to prompt the user to fill out the form automatically (using previously saved data).

In the first case (when submitting a form), isSubmission = true and _getPasswordFields(form , isSubmission) will skip the password field if it is not filled.
However, in the case of a specific site (https://account.booking.com/sign-in), logging in is performed in two stages. At the first stage, the user must enter only the name, the password field is hidden and left blank. After entering the name, the form is submitted and is ignored by the password manager for the reason stated above. If we make the specified correction, then the password manager does not ignore the form, a window opens asking you to remember the username and an empty password, but the password can be edited directly in this window. This allows the user to save credentials.
I understand that this is a very special case; most sites do not make the login procedure using two separate forms for username and password (although I did not collect statistics and maybe it is now fashionable to do so?). Therefore, I do not presume to say that this correction is necessary.

EDIT: tracking in Issue #2537 (UXP)

Thanks.

[Moonchild]

If we make the specified correction, then the password manager does not ignore the form, a window opens asking you to remember the username and an empty password, but the password can be edited directly in this window. This allows the user to save credentials.

That's nice in that particular situation, of course, but I'm afraid that might start to pop up the password manager for forms that don't actually store/use credentials?
Split login forms are... well not super rare for there's a good handful of sites I know of at least that use them, but not common either, in my experience.

I'm fine with taking the other change too as long as it doesn't actually cause annoyance for forms that have password type fields (hidden or not) but aren't actually logins.

[Kris_88]

but I'm afraid that might start to pop up the password manager for forms that don't actually store/use credentials?

Yes, this is possible. However, our password manager currently does not work on some sites, so we need to expand the list of conditions under which it will work (I mean universal conditions, since registering each site in recipes.json is a very bad option). Accordingly, the likelihood of false positives increases.
Okay, let's put this aside and don't rush into this.

I'm fine with taking the other change too as long as it doesn't actually cause annoyance for forms that have password type fields (hidden or not) but aren't actually logins.

There is another idea...
Currently, the _getFormFields() function first tries to find input fields based on recipes.json, then, if the fields are not found, it tries to look for them based on general considerations. We can add a third step: if the fields are not found, look for them based on a pair of selectors from the preferences. There is an assumption that "input[name=username]" and "input[name=password]" are quite common. Given that the querySelector() function allows a group of selectors, the user will be able to list additional options.