Closed Bug 1528715 Opened 1 year ago Closed 1 year ago

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


(Firefox for Android :: Keyboards and IME, defect, P2)

Firefox 57



Firefox 67
Tracking Status
firefox65 --- wontfix
firefox66 --- fixed
firefox67 --- verified


(Reporter: privatemeta, Assigned: JanH)



(Keywords: regression)


(2 files)

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:

Sony Xperia Z5
Android Version 7.1.1

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.


  • Have in your history
  • Have 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 "" it types the url "" or a variation

See screenshot

Expected results:

it properly types the URL
"" instead

Which keyboard are you using?

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

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)

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.

Ever confirmed: true

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

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
Pushed by
Work around problems with forcing the autocomplete result's capitalisation. r=geckoview-reviewers,m_kato
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 67

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)

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.

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

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.

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

Flags: needinfo?(privatemeta)

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.