Slow typing, delayed local-echo, while searching contacts/groups on compose screen

[gsbabil]

• [x] I have searched open and closed issues for duplicates

---

Bug description

• Keyboard local-echo of typed words in the Signal contact-list search-bar (in the "New Message" screen) is very slow using 3rd-party keyboard such as "GBoard" (Google Keyboard for iOS).

• For example, if a partial contact name "Chris" is typed with GBoard, focusing the search-bar, the word "Chris" takes about 3-5 seconds to show up in the contact-list search-bar.

• The Keyboard delay is not experienced in the following scenarios:

  • Messages typed in the conversation screen with GBoard neither in tap-typing nor in swipe-typing mode.

  • Messages typed with iOS's default keyboard in any screen.

  • This may not be entirely relevant adding for completeness: the delay with GBoard in contact-list search isn't experienced in other similar apps such as in WhatsApp, Viber etc.

Steps to reproduce

1. Install GBoard from App Store

2. Proceed to write a new message for the first time to a contact (navigate to the "New Message" screen by tapping the top-right icon from Signal's Inbox screen)

3. Type part of the contact's name in the contact-list search-bar with GBoard.

Actual result:

• The typed name/word would show up in the search-bar after a noticeable delay of ~5 seconds.

Expected result:

• Immediate local-echo/feedback of any typed words is expected in the contact-list search-bar.

• For example, if the same steps 1-3 are attempted in the conversation screen (within an ongoing conversation with a contact), the local-echo delay of the typed words/letters is not experienced with GBoard in Signal.

Device info

• Device : iPhone 6
• iOS version : 11.2.1
• Signal version : 2.19.2.0

Link to debug log

• https://gist.github.com/e5d8cecda0be6f82bd700d3f5b2d3407

Screenshots

[ThuggishNuggets]

Haven't dug into the code just yet, but the way this behavior presents makes me think there's some work happening on the foreground/main thread in response to the search text changing that should instead be dispatched to a background/global thread.

[ThuggishNuggets]

Yeah, assuming this is the correct file, all of this code is run on the main thread in response to changes to the UISearchBar's text changing, which is quite a lot.

Might be a good idea to change -updateSearchPhoneNumbers to accept a completion handler and dispatch_async the work in its body to another dispatch_queue then have it call the completion handler when it's finished.

Will work on these modifications once I get the project building on this machine (it seems the High Sierra install broke some of my tools).

[gsbabil]

• This issue persists with the latest Signal and iOS releases. I have the following at the moment and can reliably reproduce the issues:

    - Device         : iPhone 6
    - iOS version    : 11.3.1 (15E216)
    - Signal version : 2.23.4.2

• I have just posted #3304 describing a similar issue, but with the default iOS keyboard.

[michaelkirk-signal]

Your keyboard is unlikely to be the cause here, we're simply not doing a performant job of searching.

If someone wants to fire up their profiler, there's probably some low hanging fruit in the search indexing/machinery.

Caching the search index would probably be a good start.

[michaelkirk-signal]

Keyboard input should no longer be sluggish on this screen.