Open Bug 1574907 Opened 1 year ago Updated 9 months ago

Saved entry does not display password at field level when it's being set from multiple entries

Categories

(Toolkit :: Password Manager, defect, P2)

70 Branch
ARM
Android
defect

Tracking

()

Tracking Status
firefox-esr68 --- unaffected
firefox68 --- unaffected
firefox69 - fix-optional
firefox70 --- fix-optional

People

(Reporter: diana.rus, Unassigned)

References

Details

(Keywords: regression, regressionwindow-wanted)

Attachments

(1 file)

Environment
Device: Sony Xperia Z5 (Android 7.0)
Build: ESR Firefox Nightly 68.1a1(2019-08-17) Firefox Beta 69.0b15, Firefox Nightly 70.0a1(2019-08-19)

Steps to reproduce:

  1. Go to "goo.gl/vi7z6" and insert a username and password.
  2. Tap on "Login" button.
  3. Choose from the triggered doorhanger the "Remember" option.
  4. Insert a different username and password.
  5. Tap on "Login" button.
  6. From the triggered doorhanger choose "Remember".
  7. Open page "goo.gl/vi7z6" in a different tab.
  8. Tap on the username field and choose an entry.

Expected Result: The password field contains the saved password for the login entry.

Actual Result: The password field remains empty after choosing the entry.

Note

  1. The issue reproduces on tested builds: Firefox Beta 69.0b15, Firefox Nightly 70.0a1(2019-08-19)
  2. The issue does not reproduce on ESR Firefox Nightly 68.1a1(2019-08-17)
See Also: → 376674
Keywords: regression

[Tracking Requested - why for this release]: Sounds like a bad regression for login autocomplete on Android.

(In reply to Diana Rus from comment #0)

Thank you for filing this.


8. Tap on the username field and choose an entry.

Expected Result: The password field contains the saved password for the login entry.

Actual Result: The password field remains empty after choosing the entry.

So an autocomplete popup does show up for the username field but when you tap on the username row it doesn't fill the password?

Note

  1. The issue reproduces on tested builds: Firefox Beta 69.0b15, Firefox Nightly 70.0a1(2019-08-19)
  2. The issue does not reproduce on ESR Firefox Nightly 68.1a1(2019-08-17)

Is it possible to get a regression range from mozilla-central builds?

Would it be possible to get testing with the preference signon.debug enabled. I guess it would log to adb logcat?

Component: Logins, Passwords and Form Fill → Password Manager
Flags: needinfo?(diana.rus)
Priority: -- → P1
Product: Firefox for Android → Toolkit
See Also: 376674
Version: Firefox 70 → 70 Branch
Attached file LogCat-Android.txt
Flags: needinfo?(diana.rus)

Hi,
I have also checked the issue on Firefox Release 68.0.2 with Sony Xperia Z5 (Android 7.0) and does not reproduces so I will update the status for firefox-68 as unaffected.
My last info about moz-regression is that the tool stops at a build dated on 2019-05-16.
What I can provide you is a logcat. I wil try and be as minimal as I can with file size and the actions that need to be present.
Attached you have the logcat "LogCat-Android.txt", please check and see whether this helps in your investigations.

Do we have any reason to believe that this affects all mobile browsers or just Fennec?

Flags: needinfo?(MattN+bmo)

Fennec and desktop are the only apps that uses the whole Toolkit::Password Manager at the moment. Fenix only uses it for autofill heuristics, not autocomplete, so it shouldn't be affected by this specific bug though.

Flags: needinfo?(MattN+bmo)

Given that Fennec ships off ESR68 now, it doesn't sound like we need to track this then.

Does that mean that Fennec will never get the broken code of Fx69? i.e. Can we WONTFIX this bug?

Flags: needinfo?(ryanvm)

That's correct, assuming there's no chance of anything GeckoView-based ever hitting this.

Flags: needinfo?(ryanvm)

(In reply to Ryan VanderMeulen [:RyanVM] from comment #8)

That's correct, assuming there's no chance of anything GeckoView-based ever hitting this.

As of now, GV isn't using autocomplete but IMO they should eventually though those discussions haven't really happened much yet…

I will move this to P2 for now then so it's still on the radar in case GV ends up using this.

Priority: P1 → P2
See Also: → 1615676
You need to log in before you can comment on or make changes to this bug.