Autocomplete in URL bar skips incorrectly duplicates inputs when entry is in history
Categories
(Firefox for Android Graveyard :: Keyboards and IME, defect, P2)
Tracking
(firefox65 wontfix, firefox66 fixed, firefox67 verified)
People
(Reporter: privatemeta, Assigned: JanH)
References
Details
(Keywords: regression)
Attachments
(2 files)
|
86.08 KB,
image/png
|
Details | |
|
47 bytes,
text/x-phabricator-request
|
lizzard
:
approval-mozilla-beta+
|
Details | Review |
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•7 years ago
|
||
Which keyboard are you using?
| Reporter | ||
Comment 2•7 years 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)
| Assignee | ||
Comment 3•7 years 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.
| Assignee | ||
Comment 4•7 years 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 | ||
Comment 5•7 years 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.
Updated•7 years ago
|
Comment 7•7 years ago
|
||
| bugherder | ||
Comment 8•7 years ago
|
||
| bugherder | ||
| Assignee | ||
Comment 9•7 years 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?
| Reporter | ||
Comment 10•7 years 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•7 years ago
|
||
Clarification: I've fetched the nightly from the Android Play Store ("Firefox Nightly for Developers (Unreleased)")
| Assignee | ||
Comment 12•7 years 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•7 years ago
|
||
2019-02-25 no longer seems to show the problem, thank you
| Assignee | ||
Updated•7 years ago
|
| Assignee | ||
Comment 14•7 years 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
Updated•7 years ago
|
| Assignee | ||
Updated•7 years ago
|
Comment 15•7 years ago
|
||
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.
Comment 16•7 years ago
|
||
| bugherder uplift | ||
Updated•5 years ago
|
Description
•