1356996 - Url bar input freezes when inputting search terms

Status: NEW

(Firefox for iOS :: General, defect)

Description

[iain]

User Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 10_3_1 like Mac OS X) AppleWebKit/603.1.30 (KHTML, like Gecko) FxiOS/7.2b2672 Mobile/14E304 Safari/603.1.30

Steps to reproduce:

1. Set up a reasonable amount of browser history
2. Click on the url bar
3. Type in a few words


Actual results:

As I type, the UI freezes after a few characters, and any further characters that I type do not appear. Then after maybe a second (sometimes longer) it unfreezes again and all of the remaining characters (that I already typed) suddenly appear in the url bar, and some suggestions from my search history appear below the url bar (in the overlay area).


Expected results:

It should not freeze. Ideally the search results should appear asynchronously as I type, but failing that they should only be looked up after I have finished typing.

Comment 1

[iain]

Attachment: Pull request

Comment 2

[iain]

I've opened a pull request to resolve this. I believe the issue might be that the debounce time when updating the suggestions is too quick.

Right now the debounce time (ie. how long the browser waits after user input before updating suggestions) is 0.1 seconds. Ideally updating the suggestions should be done in a background thread (rather than the main thread), but at present it is not (and I wouldn't feel confident making that change to the code). But increasing the debounce time so that the suggestions are only updated after the user has paused in their typing should make the UI "freeze" less obstructive to the user.

Based on this page:

http://www.pocketables.com/archives/mobile-device-keyboard

I might expect an iOS user to type at 30wpm. According to this document:

https://arxiv.org/pdf/1208.6109.pdf

The average word length in english is 5.1 letters. Let's increase that to 6 to include spaces between words and we get a typing speed of 180 characters per minute, or a character every 0.333 seconds. Based on that the current debounce of 0.1 seconds will try to update the suggestions 3 times in the time it might take an average user to type one character.

On that basis in my pull request I've increased the debounce from 0.1 seconds to 0.5 seconds, which is slightly higher than the typing rate I'd expect (although probably too small to indicate a pause in the user's typing).