Autocomplete in URL bar skips incorrectly duplicates inputs when entry is in history

VERIFIED FIXED in Firefox 66

Status

()

defect
P2
normal
VERIFIED FIXED
3 months ago
3 months ago

People

(Reporter: privatemeta, Assigned: JanH)

Tracking

({regression})

Firefox 57
Firefox 67
All
Android
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox65 wontfix, firefox66 fixed, firefox67 verified)

Details

Attachments

(2 attachments)

Reporter

Description

3 months ago

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.109 Safari/537.36

Steps to reproduce:

Device:
Sony Xperia Z5
Android Version 7.1.1

Problem:
When an address is already in your History, and you try to enter part of that URL again, it tries to autocomplete. When you keep typing instead of selecting the autocomplete entry it suggests, it "finishes" the first part of the entry and continues typing after that.

Example:

  • Have https://reddit.com/r/politics in your history
  • Have https://reddit.com/ open in your browser
  • Go to edit the URL
  • type r/pol after the last slash
  • it suggests the full url /r/politics
  • if you press the i, it now says /r/polpoli
  • keep typing, up to /r/polpolit
  • try to keep typing, it switches to /r/polpolitpoliti
  • when you finished typing, it has the url ending /r/polpolitpolitics, or a similar variation in certain locations of the string.

Actual results:

When trying to type the URL "https://reddit.com/r/politics" it types the url "https://reddit.com/r/polpolitpolitics" or a variation

See screenshot

Expected results:

it properly types the URL
"https://reddit.com/r/politics" instead

Assignee

Comment 1

3 months ago

Which keyboard are you using?

Component: General → Keyboards and IME
Flags: needinfo?(privatemeta)
OS: Unspecified → Android
Hardware: Unspecified → All
Reporter

Comment 2

3 months ago

I'm using the built in Xperia Keyboard. It doesn't seem to be an issue with the keyboard itself though, since Firefox is the only application where this issue shows up (e.g. Chrome does not show the same behavior)

Flags: needinfo?(privatemeta)
Assignee

Comment 3

3 months ago

Yes and no - there is indeed some issue with how Firefox's autocomplete is implemented, but it also depends on the keyboard in use, as the issue you're describing certainly doesn't happen with every keyboard app.

I still have a slightly older version of the Xperia keyboard lying around on my phone from looking at bug 1344464 and while I can only get it to say /r/popolitics, maybe that could be enough in tracking down a fix if I find some time.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee

Comment 4

3 months ago

It seems that bug 1388112 broke this - apparently simply replacing parts of the existing text in order to force the history result's capitalisation for the path part confuses Sony's IME.

Assignee: nobody → jh+bugzilla
Blocks: 1388112
Keywords: regression
Version: Firefox 65 → Firefox 57
Assignee

Comment 5

3 months ago

Even though using text.replace() is supposed to keep the existing spans intact,
in practice the composition spans still get lost, even when the replacement text
is identical (because there was in fact no capitalisation difference between
user-entered text and autocomplete result).

One approach to fix this would be to manually save the composition spans and
subsequently restore them afterwards, like we already do this a few lines
further down below, in the other major code path through onAutocomplete().
However while trying to generalise that approach, the most natural approach for
the caller to specify which spans it wanted to save was to pass a Predicate
lambda to the state saving function, which for some reasons lead to strange
"Didn't find class" errors.

So instead, we just restart input for affected IMEs (i.e. Sony's keyboard) to
get them back into sync with the new contents of the EditText.

To avoid unnecessarily calling restartInput(), though, we only do this if the
user-entered text (which at this stage is known to correspond to the auto-
complete result when compared case-insensitively) actually differs from the
autocomplete result.

Priority: -- → P2

Comment 6

3 months ago
Pushed by mozilla@buttercookie.de:
https://hg.mozilla.org/integration/autoland/rev/cb52999afb25
Work around problems with forcing the autocomplete result's capitalisation. r=geckoview-reviewers,m_kato

Comment 7

3 months ago
bugherder
Status: NEW → RESOLVED
Last Resolved: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 67
Assignee

Comment 9

3 months ago

Can you check with a current Nightly build (can be installed in parallel to your normal Firefox installation and will use a separate profile) whether this is now working properly?

Flags: needinfo?(privatemeta)
Reporter

Comment 10

3 months ago

The current nightly seems to be of version 67.0a1 (2019-02-22), is that the correct version? It still shows a similar behavior, but I'm not sure if that version is still the unfixed one or if the issue itself is not fixed with that.

Reporter

Comment 11

3 months ago

Clarification: I've fetched the nightly from the Android Play Store ("Firefox Nightly for Developers (Unreleased)")

Assignee

Comment 12

3 months ago

No, the fix landed in mozilla-central (which is what the Nightlies are based on) on the 23rd, so it would have only been in the 23rd (maybe) or 24th (certainly) Nightly.

However it seems that there have in fact been no new Nightly builds for ARM since the 22nd, so you have to wait until bug 1530289 is fixed before being able to test. Sorry for the confusion.

Reporter

Comment 13

3 months ago

2019-02-25 no longer seems to show the problem, thank you

Flags: needinfo?(privatemeta)
Assignee

Updated

3 months ago
Status: RESOLVED → VERIFIED
Assignee

Comment 14

3 months ago

Comment on attachment 9045243 [details]
Bug 1528715 - Work around problems with forcing the autocomplete result's capitalisation. r?geckoview-reviewers

Beta/Release Uplift Approval Request

  • Feature/Bug causing the regression: Bug 1388112
  • User impact if declined: Sony keyboard may behave strangely in conjunction with autocompletion.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: none
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Small workaround targetted to Sony's IME, and which has already successfully been used for bug 1344464
  • String changes made/needed: none
Attachment #9045243 - Flags: approval-mozilla-beta?

Comment on attachment 9045243 [details]
Bug 1528715 - Work around problems with forcing the autocomplete result's capitalisation. r?geckoview-reviewers

Not a recent regression but the risk looks low and the fix is verified in Nightly.
OK for uplift to beta 12.

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