Closed Bug 1565318 Opened 1 year ago Closed 11 months ago

Autocomplete history dropdown text selection stops working on all tabs after adding bookmark

Categories

(Toolkit :: Autocomplete, defect, P2)

67 Branch
Desktop
All
defect

Tracking

()

VERIFIED FIXED
mozilla70
Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- fixed
firefox68 --- wontfix
firefox69 --- verified
firefox70 --- verified

People

(Reporter: 13hurdw, Assigned: surkov)

References

(Regression, )

Details

(Keywords: regression)

Attachments

(2 files)

FF 68.0
macOS 10.14.5

Autofill addresses setting unchecked

Enter login form to get autocomplete history to appear :

What happened (actual behaviour) :
Clicked autocomplete entry is highlighted blue, but is not populated to the text field.

Expected :
Clicking entry populates autocomplete entry to text field , closes autocomplete text dropdown

The priority flag is not set for this bug.
:mak, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(mak77)

Is this a recent regression, or has it always been broken?

Flags: needinfo?(mak77) → needinfo?(13hurdw)

(In reply to Marco Bonardo [::mak] from comment #2)

Is this a recent regression, or has it always been broken?

I started encountering it in the past few releases . Not sure how long it's been broken, but I think it was working pre-Quantum IIRC.

Flags: needinfo?(13hurdw)

The priority flag is not set for this bug.
:mak, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(mak77)

MattN, any idea who may look into this form fill bug? It may be an annoyance on Mac (note: I didn't try to repro)

Flags: needinfo?(mak77) → needinfo?(MattN+bmo)
Priority: -- → P2

The direct URL is https://www.pastemagazine.com/noisetrade/reset-password/ btw. The one in the iframe can show an ad instead of the actual continue button if you don't have an ad blocker :(

Unfortunately I cannot reproduce the problem on 10.13.6 on Firefox 68.0.1 or 70.0a1. Clicking on the autocomplete popup fills the word "example" and I tried different methods of opening the popup and different methods of filling (mouse & keyboard).

Can you attach logs from the Browser Console? Open the Browser Console from the Developer Tools menu and then right-click on a message and choose "Export visible messages to clipboard". Then you can paste it in the top box at this page.
Can you also try reproduce the problem in Safe Mode (see the option in the help menu)? If that works, it's likely caused by one of your extensions (though I don't think that should be possible).

Thank you

Flags: needinfo?(MattN+bmo) → needinfo?(13hurdw)

(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #6)

The direct URL is https://www.pastemagazine.com/noisetrade/reset-password/ btw. The one in the iframe can show an ad instead of the actual continue button if you don't have an ad blocker :(

Unfortunately I cannot reproduce the problem on 10.13.6 on Firefox 68.0.1 or 70.0a1. Clicking on the autocomplete popup fills the word "example" and I tried different methods of opening the popup and different methods of filling (mouse & keyboard).

Can you attach logs from the Browser Console? Open the Browser Console from the Developer Tools menu and then right-click on a message and choose "Export visible messages to clipboard". Then you can paste it in the top box at this page.
Can you also try reproduce the problem in Safe Mode (see the option in the help menu)? If that works, it's likely caused by one of your extensions (though I don't think that should be possible).

Thank you

@MattN weird, they changed the password reset.
Ok, so I think I figured out what is causing this, I couldn't reproduce in a new tab in a separate window (I have multiple windows open each with multiple tabs) , until I added a bookmark and selected a bookmark tag from the autocomplete dropdown menu.

After that, both the autocomplete in the bookmark UI and on pages no longer works.

Steps to reproduce:

The autocomplete selection stops working (in both the page DOM and bookmark UI) after a bookmark is added .

Flags: needinfo?(13hurdw)
Summary: Autocomplete history dropdown text selection does not populate text field → Autocomplete history dropdown text selection stops working on all tabs after adding bookmark

I see something similar in the Tags field indeed, it works correctly with the keyboard, but doesn't fill with the mouse.
Maybe something with the controller, that is the same for every autocomplete field around.

A regression range from mozregression would be really useful: https://mozilla.github.io/mozregression/

Flags: needinfo?(MattN+bmo)

Managed to reproduce with :atrif on Windows 10 and macOS 10.14 so updating the flags for the bug.
STR used where:

  • access about:preferences;
  • disable Autofill addresses option;
  • access https://www.w3schools.com/TAGs/tryit.asp?filename=tryhtml5_form_autocomplete
  • fill in the user/mail fields;
  • set a bookmark + tag on that page;
  • refresh the page;
  • click inside the user/mail fields type the 1st input letter and click on the autofill options;
  • open a new tab, access any webpage;
  • bookmark that page and type the 1st letter of the previously used tag
  • click (don't use the keyboard) on the autocomplete row
Status: UNCONFIRMED → NEW
Has Regression Range: --- → yes
Has STR: --- → yes
Ever confirmed: true
Flags: needinfo?(surkov.alexander)
OS: Unspecified → All
Regressed by: 1525101
Hardware: Unspecified → Desktop

(In reply to Cristian Fogel, QA [:cfogel] from comment #10)

  • bookmark that page and type the 1st letter of the previously used tag

hm, bookmark tag autocomplete is shown for me on nightly (70.0a) on os x 10.14.6

Flags: needinfo?(surkov.alexander)

(In reply to alexander :surkov (:asurkov) from comment #11)

(In reply to Cristian Fogel, QA [:cfogel] from comment #10)

  • bookmark that page and type the 1st letter of the previously used tag

hm, bookmark tag autocomplete is shown for me on nightly (70.0a) on os x 10.14.6

Does the content autocomplete still work at that point? I think it may be a mistake in the STR.

Assignee: nobody → surkov.alexander
Status: NEW → ASSIGNED
Flags: needinfo?(MattN+bmo) → needinfo?(surkov.alexander)
Version: 68 Branch → 67 Branch

The autocomplete tag is shown, but clicking on it has no effect.

See Also: → 1573052
See Also: 1573052
Duplicate of this bug: 1573052

(In reply to Cristian Fogel, QA [:cfogel] from comment #13)

The autocomplete tag is shown, but clicking on it has no effect.

not sure I have realiable steps to reproduce, but I indeed saw that clicking an autocomplete item have no effect. That time I saw that mouseup event listener didn't trigger [1] at all. I wonder if it could be because initialize() was called twice (for example, once on this.richlistbox access and second time on _openAutocompletePopup call). In that case, richlistbox will be recreated, but event listeners won't be readded.

[1] https://searchfox.org/mozilla-central/source/toolkit/content/widgets/autocomplete-popup.js#62

Flags: needinfo?(surkov.alexander)
Pushed by mozilla@noorenberghe.ca:
https://hg.mozilla.org/integration/autoland/rev/9d7f7afb8952
avoid richlistbox-popup duping initialization r=MattN
Status: ASSIGNED → RESOLVED
Closed: 11 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla70

This sounds like something we'll probably want Beta & ESR68 approval requests on.

Flags: qe-verify+
Flags: needinfo?(surkov.alexander)

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

This sounds like something we'll probably want Beta & ESR68 approval requests on.

I'm not sure if anyone has verified it in Nightly yet. 13hu, would you kindly check it?

Flags: needinfo?(surkov.alexander) → needinfo?(13hurdw)

Comment on attachment 9085129 [details]
Bug 1565318 - avoid richlistbox-popup duping initialization

Beta/Release Uplift Approval Request

  • User impact if declined: Broken Firefox bookmark tagging
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: see comment #0 and comment #10
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): just correctness fix, it removes possible timing collisions during popup control initialization
  • String changes made/needed: no
Attachment #9085129 - Flags: approval-mozilla-beta?

(In reply to alexander :surkov (:asurkov) from comment #21)

  • Is this code covered by automated tests?: No

The autocomplete code is covered by many tests, the new change isn't specifically tested though.

  • User impact if declined: Broken Firefox bookmark tagging

It's much worse than that… it's broken autocomplete throughout the whole browser include form history, login, or address autocomplete.

QA Whiteboard: [qa-triaged]

Verified with 70.0a1 (2019-08-21) on Windows 10 and macOS 10.14.
Waiting for the beta builds.

Status: RESOLVED → VERIFIED

(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #22)

(In reply to alexander :surkov (:asurkov) from comment #21)

  • Is this code covered by automated tests?: No

The autocomplete code is covered by many tests, the new change isn't specifically tested though.

right, wasn't sure what exactly the question asks for, whether this particular change is tested or related code has tests coverage

  • User impact if declined: Broken Firefox bookmark tagging

It's much worse than that… it's broken autocomplete throughout the whole browser include form history, login, or address autocomplete.

thanks for the correction! got wrong impression from str

Cancelling ni? from 13hu per comment #23

Flags: needinfo?(13hurdw)

Comment on attachment 9085129 [details]
Bug 1565318 - avoid richlistbox-popup duping initialization

Fixes some pretty severe usability regressions for some users. Approved for 69.0b16.

Attachment #9085129 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

Verified with 69.0b16 on Windows10, macOS 10.15, Ubuntu 18.04.

Is this something we should consider backporting to ESR68 as well?

Flags: needinfo?(surkov.alexander)

Comment on attachment 9085129 [details]
Bug 1565318 - avoid richlistbox-popup duping initialization

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: Broken Firefox UI
  • User impact if declined: autocomplete is broken throughout the whole browser, includes form history, login, address autocomplete.
  • Fix Landed on Version: 69
  • Risk to taking this patch: Medium
  • Why is the change risky/not risky? (and alternatives if risky): relatively small patch, code correctness, shouldn't be risky
  • String or UUID changes made by this patch: no
Flags: needinfo?(surkov.alexander)
Attachment #9085129 - Flags: approval-mozilla-esr68?

Comment on attachment 9085129 [details]
Bug 1565318 - avoid richlistbox-popup duping initialization

Fixes autocomplete bustage. Approved for 68.2esr.

Attachment #9085129 - Flags: approval-mozilla-esr68? → approval-mozilla-esr68+
You need to log in before you can comment on or make changes to this bug.