1548875 - Notify LoginManagerParent about edits to password fields after generation

Status: RESOLVED FIXED

(Toolkit :: Password Manager, enhancement, P2)

Description

[Matthew N. [:MattN]]

If a user edits a field we filled with a generated password, propagate the user edits to our local cache storage to ensure the resulting password is available for later saving and for filling into other fields.

We should consider only looking for user edits with isTrusted:true to ignore mungeing done by the site for presentation purposes only.

Comment 1

[Sam Foster [:sfoster] (he/him)]

I just want to check my understanding of the goal if this bug - which is to handle the case where a user edits the value of a field we had filled with a generated password? E.g. to add special characters, or whatever.

That seems like we would want to update the value in _generatedPasswordsByPrincipalOrigin
...but we'll not know if they just added some special characters, or if they cleared the whole thing and input their own? It only matters in that we'll suggest this password for password fields at the same origin with the label "Use generated password" - for a password that may not resemble the originally generated value at all?

Comment 2

[Matthew N. [:MattN]]

As the spreadsheet says, I think this depends on bug 1548861 since it's very similar and may end up replacing this bug.

Comment 3

[Matthew N. [:MattN]]

I'm morphing this bug a bit to unblock bug 1548880.

Comment 4

[Matthew N. [:MattN]]

Attachment: Bug 1548875 - Notify LoginManagerParent the same way when a generated password is filled or edited. r=sfoster

Tests will be added in bug 1548861 and bug 1548874.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e7253ee70f81
Notify LoginManagerParent the same way when a generated password is filled or edited. r=sfoster

Comment 6

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/mozilla-central/rev/e7253ee70f81

Comment 7

[Daniel Bodea [:danibodea]]

1. So far, I understand that the steps to reproduce would start with generating a password (Password Manager drop-down and context menu methods), then modify the generated password (erase a part of it or add to it or change it in any way) and then, the LoginManagerParent should somehow be notified. How should this be verified?
   Also, how do I differentiate an "isTrusted:true" event from one that is false? What do I need to take into consideration when testing?

Thanks!

Comment 8

[Matthew N. [:MattN]]

(In reply to Bodea Daniel [:danibodea] from comment #7)

1. So far, I understand that the steps to reproduce would start with generating a password (Password Manager drop-down and context menu methods), then modify the generated password (erase a part of it or add to it or change it in any way) and then, the LoginManagerParent should somehow be notified.

That is correct.

How should this be verified?

I think it will be easiest to verify bug 1548861 and bug 1548880 which depend on this one.

Also, how do I differentiate an "isTrusted:true" event from one that is false? What do I need to take into consideration when testing?

isTrusted is true when the event is dispatched by the browser instead of by a website. You can dispatch an untrusted event on any <input> by first selecting it in the Inspector of web developer tools and the running the following in the console:

$0.dispatchEvent(new Event("change"));

and ensuring that it doesn't trigger a new doorhanger or a change to the content of an existing one.