Closed Bug 1548875 Opened 2 years ago Closed 1 year ago

Notify LoginManagerParent about edits to password fields after generation

Categories

(Toolkit :: Password Manager, enhancement, P2)

enhancement

Tracking

()

RESOLVED FIXED
mozilla70
Tracking Status
firefox70 --- fixed

People

(Reporter: MattN, Assigned: MattN)

References

Details

(Whiteboard: [passwords:generation] [skyline])

Attachments

(1 file)

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.

Flags: qe-verify+
Depends on: 1548880
Whiteboard: [skyline] → [passwords:generation] [skyline]

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?

Assignee: nobody → sfoster
Status: NEW → ASSIGNED

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

Assignee: sfoster → nobody
Status: ASSIGNED → NEW

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

Assignee: nobody → MattN+bmo
Blocks: 1548880, 1548861
Status: NEW → ASSIGNED
No longer depends on: 1548861, 1548880
Summary: Update cache with edits to password fields after generation (when there were saved logins for the site) → Notify LoginManagerParent about edits to password fields after generation
Pushed by mozilla@noorenberghe.ca:
https://hg.mozilla.org/integration/autoland/rev/e7253ee70f81
Notify LoginManagerParent the same way when a generated password is filled or edited. r=sfoster
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla70
  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!

Flags: needinfo?(MattN+bmo)

(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.

Flags: qe-verify-
Flags: qe-verify+
Flags: needinfo?(MattN+bmo)
You need to log in before you can comment on or make changes to this bug.