1794933 - Report of autocomplete suggestion from history lingering after nonmatching input

Status: RESOLVED FIXED

(Fenix :: Toolbar, defect)

Description

[Christian Sadilek [:csadilek]]

From github: https://github.com/mozilla-mobile/android-components/issues/3611.

Following is an example but not the exact URL scenario. @dholbert says it seems to be happening infrequently with history URLs.

"I started typing "yahoo", and y autocompleted to yelp.com, and then I typed "ah" and I was briefly looking at "yah[elp.com]" but then after ~1 second of looking at that, it fixed itself"

STR:
When opening Fenix (usually from fresh launch)

1. Open search
2. Type "a" ("[mazon.com]" suggested)
3. Type something that doesn't match the suggestion, ie "aa"

Expected:
Suggestion updates

Actual:
"[mazon.com]" remains as the autocomplete suggestion like "aaa[mazon.com]". Needs to be backspaced to delete it

┆Issue is synchronized with this Jira Task

Change performed by the Move to Bugzilla add-on.

Comment 1

[Daniel Holbert [:dholbert]]

(chiming in, since I'm quoted as an affected-user in the original bug on github):
I can still reproduce this as-described in https://github.com/mozilla-mobile/android-components/issues/3611#issuecomment-507411437 (where broken rendering only sticks around for a fraction of a second). I just hit it now; I'll post a screenshot.

I feel like I've seen this ~recently where the rendering sticks around longer, too (as noted in the last paragraph of that same 2019 github comment), but I don't remember precisely when.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: screenshot of bug (showing bogus "ye[outube.com]" autocompletion)

Here's a screenshot of the bug, following similar steps to what I described on github, though my autocompletion results are a bit different now.

(1) type "y"
--> My fenix autocompletes to y[outube.com]
(2) Type "e"
--> the "e" gets inserted but the autocompletion suffix remains, so now it shows "ye[outube.com]" as shown in screenshot, which is a bogus autocompletion (could even be a malicious site for all we know)
(3) After a short period of time, the autocompletion updates to "ye[lp.com]"

The EXPECTED RESULT here is that we should never show "residual cruft" from previous no-longer-valid autocompletions. In particular, we should never show "ye[outube.com]" as we did in the attached screenshot.

Comment 3

[Petru-Mugurel Lingurar [:petru]]

Can see it (not always) if slowing down a screen recording and scrubbing the video.
For me it's a very small delay but it's there. Looks like something that can be fixed.

Comment 4

[BMO Automation]

Attachment: GitHub Pull Request

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:cpeterson, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 6

[BMO Automation]

Attachment: GitHub Pull Request

Comment 7

[Petru-Mugurel Lingurar [:petru]]

Issue should be fixed in tomorrow's Nightly.

Comment 8

[Ryan VanderMeulen [:RyanVM]]

https://github.com/mozilla-mobile/firefox-android/commit/fe733d3478b0ea755ddecbd52b7ca99ef474ad94

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c52311dd03a9
Remove autocomplete when not applicable anymore