My mother is having problems with her installation of Firefox 115 (x64,
Win10).

For some web sites which use a user account (eg a credit card site and a
gas/electricity meter site), the process of creating a new account (choose
username [typically an email address] and password) or modifying an existing
password (using the site's "forgotten password" mechanism) is failing. It
appears to succeed but the chosen username/password are not accepted.

I have proved that the invisible text (passwords) is definitely being typed
correctly when a password is defined and then when it is used, by typing it
in Wordpad (so it is visible) and then copy/pasting it into the new-password
field and into the logon password field. This eliminates typos and caps-lock
problems. The fact that I've seen it myself for two of her sites, with
others suspected but not yet tested, suggests some sort of systematic fault
in her profile.

If the same account creation/modification process for a site is performed in
Google Chrome, everything is OK. It is then possible to log in to the site
using the chosen username/password, either from Chrome or FF.

I've tried clearing (History | Clear Recent History) for time range
"Everything".

- browsing & download history
- cookies
- cache

- Data | Offline web site data

And then closing and restarting FF. That doesn't help.

It only affects the initial definition of the logon parameters. Once an
account has been set up (in Chrome), there is no problem with repeatedly
logging into the site, either by explicitly typing the username/password or
by saving them to Saved Passwords and letting FF auto-populate the fielsds.

Is this a symptom that's ever been reported before? Is there a known fix,
other that deleting and creating a new Firefox profile? I'm reluctant to do
that because of the problem of retaining all the saved logins (FF
auto-populates the user name/password fields for known websites).

Should I have cleared Data | Site settings as well?

NY <me@privacy.invalid> wrote:

>My mother is having problems with her installation of Firefox 115 (x64,
>Win10).

>For some web sites which use a user account (eg a credit card site and a
>gas/electricity meter site), the process of creating a new account (choose
>username [typically an email address] and password) or modifying an existing
>password (using the site's "forgotten password" mechanism) is failing. It
>appears to succeed but the chosen username/password are not accepted.

>I have proved that the invisible text (passwords) is definitely being typed
>correctly when a password is defined and then when it is used, by typing it
>in Wordpad (so it is visible) and then copy/pasting it into the new-password
>field and into the logon password field. This eliminates typos and caps-lock
>problems.

I believe you that it's not behaving. However, I will point out that
there are Web sites that block pasting into a password field via the
usual methods of right-click > paste and CTRL-V. It's annoying.

>The fact that I've seen it myself for two of her sites, with
>others suspected but not yet tested, suggests some sort of systematic fault
>in her profile.

>If the same account creation/modification process for a site is performed in
>Google Chrome, everything is OK. It is then possible to log in to the site
>using the chosen username/password, either from Chrome or FF.

>I've tried clearing (History | Clear Recent History) for time range
>"Everything".

>- browsing & download history
>- cookies
>- cache

>- Data | Offline web site data

>And then closing and restarting FF. That doesn't help.

Check to see if she's already storing credentials within Firefox specific
to the site, then clear that.
about:preferences > Privacy > Logins and Passwords

There could be an Add-On or extension in conflict. Try Help >
Troubleshoot Mode and make sure you DO NOT choose "refresh".

>It only affects the initial definition of the logon parameters. Once an
>account has been set up (in Chrome), there is no problem with repeatedly
>logging into the site, either by explicitly typing the username/password or
>by saving them to Saved Passwords and letting FF auto-populate the fielsds.

>Is this a symptom that's ever been reported before? Is there a known fix,
>other that deleting and creating a new Firefox profile? I'm reluctant to do
>that because of the problem of retaining all the saved logins (FF
>auto-populates the user name/password fields for known websites).

>Should I have cleared Data | Site settings as well?

"Adam H. Kerman" <ahk@chinet.com> wrote in message
news:u8gtnk$2hck3$1@dont-email.me...
> I believe you that it's not behaving. However, I will point out that
> there are Web sites that block pasting into a password field via the
> usual methods of right-click > paste and CTRL-V. It's annoying.

Thanks for your suggestions.

I know about that pasting problem with some sites, but I did try explicitly
typing the username (email address) and password, as well as pasting it in
from Notepad and retrieving it from about:preferences > Privacy > Logins and
Passwords

I'll try Help | Troubleshoot Mode - I'd forgotten about that. Thanks for the
warning about not refreshing the profile!

I'll report back if it doesn't help. It's a weird one: a browser which seems
to mess up the registration process for some web sites but which allows
logon if another browser is used to do the initial registration.

Adam H. Kerman wrote:

> there are Web sites that block pasting into a password field via the
> usual methods of right-click > paste and CTRL-V.

Sometimes disabling javascript allows paste to work, but the type of
sites that block pasting are most likely to rely on javascript for the
site to function at all ...

"Andy Burns" <usenet@andyburns.uk> wrote in message
news:kh4iukFe5t1U1@mid.individual.net...
> Adam H. Kerman wrote:
>
>> there are Web sites that block pasting into a password field via the
>> usual methods of right-click > paste and CTRL-V.
>
> Sometimes disabling javascript allows paste to work, but the type of sites
> that block pasting are most likely to rely on javascript for the site to
> function at all ...

And that doesn't explain why the registration process fails even when the
password is entered by typing.

Consider the stages:

1. registration of account: user types desired username (email address) and
password

2. logon: user types (or does copy/paste) of those details onto the logon
screen

The fact that stage 1 appears to fail if executed on FF (but not if it is
done on Chrome) whereas stage 2 always works, for both copy/paste and
retype, suggests that something is going wrong with the registration process
when FF is used.

The error is of the form "bad user or password" which suggests that the
account is not being created or else is being created with incorrect
information (ie not what the user typed).

I reproduced it in FF (with barclaycard.co.uk) from my mum's PC (via
Teamviewer), firstly with all details typed into the registration form and
secondly with the password type into Notepad and the copy/pasted from there
to the registration form. Having *apparently* registered correctly on both
occasions (no failure message), I tried logging in from Chrome and then FF -
"bad username/password" error. I then repeated the registration from Chrome
and first logged in from FF: success. Subsequent logon from Chrome (for
completeness) also worked.

If I had the inclination, I'd do a Wireshark scan and try to see what LAN
traffic is being sent between the PC and the server during registration, but
I imagine I'd come up against the brick walls of a) encryption and b)
different results every time due to time-sensitive encryption key.

For the next site that she needs me to do, I'm going to try first of all
registering from *my* PC and FF, to distinguish between a generic FF problem
and one that only affects her installation of FF. I'm also going to try an
registration on her PC in FF Troubleshooting Mode.

NY wrote:

> If I had the inclination, I'd do a Wireshark scan and try to see what
> LAN traffic is being sent between the PC and the server during
> registration, but I imagine I'd come up against the brick walls of a)
> encryption and b) different results every time due to time-sensitive
> encryption key.

I'd have to be *very* inclined to try that, Telerik Fiddler looks like
it's no longer free past a trial period?

AFAIK browsers still support SSLKEYLOGFILE, so you can decrypt SSL in
..pcap files after the fact ...

Andy Burns <usenet@andyburns.uk> wrote:
>Adam H. Kerman wrote:

>>there are Web sites that block pasting into a password field via the
>>usual methods of right-click > paste and CTRL-V.

>Sometimes disabling javascript allows paste to work, but the type of
>sites that block pasting are most likely to rely on javascript for the
>site to function at all ...

I should mention that javascript can be used to disable access to the
submenu with right click, which includes copy and paste commands. I use
the Absolute Enable Right Click add on because I won't put up with such
nonsense. Nevertheless, I have found sites blocking pasting into the
password field.

Yes, your right, disallowing javascript would make the Web site
unusable.

Adam H. Kerman wrote:

> Absolute Enable Right Click

Sounds good, but perhaps a double-edged sword?

"Please Note: Enabling copy may break some websites functionality."

Andy Burns <usenet@andyburns.uk> wrote:
>Adam H. Kerman wrote:

>>Absolute Enable Right Click

>Sounds good, but perhaps a double-edged sword?

>"Please Note: Enabling copy may break some websites functionality."

Yes. That's true. There are Web sites it conflicts with. I enable it one
Web site at a time if I find that right click is blocked. I don't enable
it where right click isn't blocked.

But I'm fed up with Web sites that use javascript and other techniques
to break the user's experience. Sometimes this add on can be used to fight
against that nonsense.