fix(developer): resync model and keyboard after device switch in Server

[mcdurdin]

When a new OSK is attached, we need to set its active keyboard and lexical model. These are undocumented API contracts between Keyman Engine for Web and Keyman Developer Server, so this appears to have changed in v.19 for keyboards (although the sync is also necessary for v.18).

• Keyboards: before this fix, the keyboard would be blank or missing after switching devices, until another keyboard was selected from the keyboard menu.
• Models: before this fix, the banner would disappear after switching devices, until another model was selected from the model menu.

@ermshiperete the behaviour for active keyboard has changed between v.18 and v.19. In v.18, switching device, the new osk would receive the active keyboard automatically. But in v.19, we need to assign it in Server. I think we may need to track where the change originates in case it impacts other use cases?

Fixes: #15217
Test-bot: skip

[keymanapp-test-bot]

User Test Results

Test specification and instructions

User tests are not required

Test Artifacts

• Developer
  • Keyman Developer - build : all tests passed (no artifacts on BuildLevel "build")
  • Compiler Regression Tests - build : all tests passed (no artifacts on BuildLevel "build")
  • Keyman Developer (old PRs) - build : all tests passed (no artifacts on BuildLevel "build")
  • kmcomp.zip - build : all tests passed (no artifacts on BuildLevel "build")
  • kmcomp.zip (old PRs) - build : all tests passed (no artifacts on BuildLevel "build")
• Keyboards
  • Test Keyboards - build : all tests passed (no artifacts on BuildLevel "build")

[ermshiperete]

@ermshiperete the behaviour for active keyboard has changed between v.18 and v.19. In v.18, switching device, the new osk would receive the active keyboard automatically. But in v.19, we need to assign it in Server. I think we may need to track where the change originates in case it impacts other use cases?

Yes, I think it would be good to investigate what changed that causes this different behaviour.

[mcdurdin]

Yes, I think it would be good to investigate what changed that causes this different behaviour.

A bisect showed that this regressed in 19.0.241 with the merge of #16015. That's going to be hard to bisect further! I will attempt to step-through the source.

[mcdurdin]

After #16156 lands, activeKeyboard is properly set automatically again.

Suggested change

	// After attaching a new OSK, we also need to set the OSK's active keyboard
	// and model
	newOSK.activeKeyboard = keyman.contextManager.activeKeyboard; // Note: undocumented KeymanWeb API refs on both sides
	// After attaching a new OSK, we also need to set the OSK's active model

@ermshiperete, should model attachment be resolved web-side also?

[mcdurdin]

Returned to draft in order to discuss whether model fix should be done in Keyman Engine set osk() rather than in Server?