Open Bug 1639295 Opened 4 years ago Updated 2 years ago

Dismissed login capture doorhanger does not show on edit when login fields are together in a Shadow Root with a "form" ancestor that is not in a Shadow Root

Categories

(Toolkit :: Password Manager, defect, P3)

defect

Tracking

()

People

(Reporter: bdanforth, Unassigned)

References

(Blocks 1 open bug)

Details

Based on the _onPasswordEditedOrGenerated callback, a dismissed doorhanger should appear when:

  • The user edits a password field (Bug 1536728)
  • The user edits a username field (when a matching password field has already been filled)

(There may be other cases as well that I'm not aware of yet.)

Currently, for the two above cases the dismissed capture on edit doorhanger does not show when the username and password fields are together in a Shadow Root with a "form" ancestor that is not in a Shadow Root (e.g. https://bugs.mattn.ca/pwmgr/login_and_change_form.html#shadow-inside-form from Bug 1629226).

Password field:

STR:

  1. Go to https://bugs.mattn.ca/pwmgr/login_and_change_form.html#shadow-inside-form.
  2. In any of the forms (e.g. "Registration form") from the "Form contents inside a Shadow Root" section, enter some value(s) into the password field
  3. Blur the field

Actual results:
There is no key icon in the URL bar.
This would, when clicked, open the dismissed login capture doorhanger.

Expected results:
There is a key icon in the URL bar.

Username field:

STR:
Building off the STR for the password field:

  1. With the password field non-empty from above, enter some value(s) into the username field
  2. Blur the field

Actual results:
There is no key icon in the URL bar.

Expected results:
There is a key icon in the URL bar.

Summary: Dismissed login capture doorhanger does not show on edit when login fields are together in a Shadow Root with a "form" ancestor that is not → Dismissed login capture doorhanger does not show on edit when login fields are together in a Shadow Root with a "form" ancestor that is not in a Shadow Root
No longer depends on: 1638587
Severity: -- → S2
Priority: -- → P1

S1 or S2 bugs needs an assignee - could you find someone for this bug?

Flags: needinfo?(MattN+bmo)

(In reply to Rachel Tublitz [:rachel] from comment #1)

S1 or S2 bugs needs an assignee - could you find someone for this bug?

That's news to me. I see it wasn't in the initial announcement doc but is now on the severity documentation. We really need to discuss/announce these changes better.

Bianca will work on this eventually so assigning her… otherwise we could lower severity…

Assignee: nobody → bdanforth
Status: NEW → ASSIGNED
Flags: needinfo?(MattN+bmo)

(In reply to Matthew N. [:MattN] from comment #2)

(In reply to Rachel Tublitz [:rachel] from comment #1)

S1 or S2 bugs needs an assignee - could you find someone for this bug?

That's news to me. I see it wasn't in the initial announcement doc but is now on the severity documentation. We really need to discuss/announce these changes better.

Matt, I'm reviewing that discrepancy in the doc now. I'm thinking the requirement is something that was missed in editing.

Thanks!

Assignee: bdanforth → nobody
Status: ASSIGNED → NEW
Priority: P1 → P3
Severity: S2 → S3
You need to log in before you can comment on or make changes to this bug.