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

[jahorton]

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
• 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.

[sgschantz]

I saw this on my own device today running Keyman 18 beta. I also got the suggestion banner back by enabling Allow Full Access. I don't know what caused the banner to get replaced with the Keyman logo and have been unable to reproduce.

[jahorton]

I wonder if there's a possibility of relationship to #13102. If the predictive-text model were to go inaccessible...

• the banner would likely be replaced with the Keyman logo
• and with "Allow Full Access" off, we wouldn't get any Sentry report about it.

Though, since we do get reports for #13102, if they were related, we ought to see some sort of error about this.

[sentry]

Sentry Issue: KEYMAN-WEB-MM

[jahorton]

After a dive into device Console logs via Simulator, I've found that toggling "Allow Full Access" after the system keyboard has been active will terminate the existing instance and start it fresh when next used; the toggle has the effect of "turning it off and on again."

Terminating plugin Tavultesoft.Keyman.SWKeyboard of Tavultesoft.Keyman because access to the kTCCServiceKeyboardNetwork service changed.

The above line occurred (among many) when I toggled "Allow Full Access" after having used the Keyman system keyboard.

[jahorton]

On the linked Sentry issue:

Error

importScripts@[native code]
importScripts@[native code]
loadModelFile@blob:null/82fc6cbe-2267-435b-836f-48d9918f7610:1:63802
handleMessage@blob:null/82fc6cbe-2267-435b-836f-48d9918f7610:1:64420
onMessage@blob:null/82fc6cbe-2267-435b-836f-48d9918f761...

importScripts is the Web Worker command we use to import a model's file into worker space.

In the breadcrumbs:

Error occurred when attempting to load dictionary

This corresponds to this section:

keyman/web/src/engine/predictive-text/worker-thread/src/main/index.ts

Lines 245 to 253 in 28151ad

	private loadModelFile(url: string) {
	// The self/global WebWorker method, allowing us to directly import another script file into WebWorker scope.
	// If built correctly, the model's script file will auto-register the model with loadModel() above.
	try {
	this._importScripts(url);
	} catch (err) {
	this.error("Error occurred when attempting to load dictionary", err);
	}
	}