keymanapp / keymanapp/keyman

bug(ios): suggestion banner stops working until full access setting is manipulated

Open
#12,213 5 comments 0 reactions 0 assignees View on GitHub
bug ios/
Dominant language
Pascal
Stars
534
Forks
143
Avg merge
2d 10h
Merged PRs (30d)
113

Description

### Describe the bug

From the community site forums @ https://community.software.sil.org/t/the-suggestions-bar-keeps-disappearing-on-iphone/9027:

> I have created a keyboard layout and added simple wordlist model to it for Armenian a while ago. It worked perfectly well until one of the recent updates that has improved the functionality of the bar significantly, but **it also introduced a problem: the bar disappears after a while and is replaced with the Keyman logo.** I have to go disable the full access and enable it back to get Keyman restarted and get the suggestions back. But it does not take very long before they disappear again. How can I try to fix the problem?

Key detail: after a period of use - which generally isn't long for this user - the suggestion banner just... permanently breaks until something resets the system keyboard.

My personal inferences:
- "one of the recent updates" - the update to 17.0-stable, since that's when the enhanced banner landed
- "disable the full access and enable it back to get Keyman restarted" - manipulating an iOS-specific setting has an effect on the bug, so it's most likely iOS-related in some manner.

After being requested to do so, the user reinstalled the default keyboard (and model); I requested this since there's a chance default-keyboard behaviors could be related. It appears to have... slowed down how quickly the issue triggers, but it does still trigger. Furthermore, the suggestion banner appears to be broken for _both_ keyboards whenever it triggers, not resetting when the active Keyman keyboard is swapped.

### Reproduce the bug

No known repro yet.

### Expected behavior

The suggestion banner should always be displayed if the active keyboard has a matching lexical model (dictionary) installed.

### Related issues

_No response_

### Keyman apps

- [ ] Keyman for Android
- [X] Keyman for iPhone and iPad
- [ ] Keyman for Linux
- [ ] Keyman for macOS
- [ ] Keyman for Windows
- [ ] Keyman Developer
- [ ] KeymanWeb
- [ ] Other - give details at bottom of form

### Keyman version

17.0.328

### Operating system

iOS 17.6.1

### Device

iPhone 11 Pro Max

### Target application

any

### Browser

_No response_

### Keyboard name

_No response_

### Keyboard version

_No response_

### Language name

_No response_

### Additional context

I have searched our Sentry error reports for potential related issues. Around the timestamps reported by the user, so far we have no matching Sentry events. This is _despite_ errors existing from _other_ sources that I would consider potentially-related:
- "The OS watchdog terminated your app, possibly because it overused RAM."
- Loading lexical models _does_ mean using extra memory, and this would be an iOS-specific scenario to handle.
- "Error occurred when attempting to load dictionary"
- That'd make a pretty solid case for a disabled banner - if the lexical model file became unavailable to load. But we're getting no such events from this user's device.
- "Cannot find the EuroLatin (SIL) keyboard for English at [...]"

The fact that we're getting none of these, plus the bug, really makes me wonder. I'll double-check that the "Allow Error Reporting" toggle is activated and green, to be extra-explicit first.

Assuming the toggle is on... this would suggest that the models should be loading correctly, but they're not properly triggering the banner? Or perhaps the model's link to the active keyboard is somehow being disrupted. But these... should be Web-internal, not iOS specific. Yet we're only getting reports of this from iOS.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.