Thank you for contributing a fix to this issue!

The test should go into this file: engine/src/flutter/lib/web_ui/test/engine/text_editing_test.dart. This file has many tests that do various things that you can copy from.

Here's how the test could look like:

1. Create a text field using the showKeyboard helper.
2. Set composingText to a non-null value.
3. Send a TextInput.setEditingState.
4. Expect the selection change hasn't been applied using checkInputEditingState.

These are some tests that may be relevant / similar to what you'll be writing:

• flutter/engine/src/flutter/lib/web_ui/test/engine/text_editing_test.dart

  Line 1761 in e0676b4

  showKeyboard(inputType: 'text');

• flutter/engine/src/flutter/lib/web_ui/test/engine/text_editing_test.dart

  Line 544 in e0676b4

  editingStrategy.composingText = '뮤';

• flutter/engine/src/flutter/lib/web_ui/test/engine/text_editing_test.dart

  Lines 689 to 696 in e0676b4

  	const MethodCall setEditingState = MethodCall('TextInput.setEditingState', <String, dynamic>{
  	'text': 'abcd',
  	'selectionBase': 2,
  	'selectionExtent': 3,
  	});
  	sendFrameworkMessage(codec.encodeMethodCall(setEditingState));
  	checkInputEditingState(textEditing!.strategy.domElement, 'abcd', 2, 3);

I hope this helps. Let me know if you have any more questions.

LGTM! Thanks for contributing the fix!

Thank you for your contribution and patience @koji-1009. I'm not sure if the selection being updated while composing is the root cause of the issue here.

When logging myself I see a few things,

1. Sometimes the composing range cannot be determined in cases where the selection extent becomes smaller than the composing text extent.
2. The framework is sending an update to the engine when we press shift + arrow key right/left.

I think 2 is important here because we want all text editing shortcuts to be handled natively on the web, so the framework shouldn't be sending this update when shift + arrow key right/left is pressed. I think 1 is less important since it doesn't interfere with the native webs composition, since composing range does not exist in native web and is not applied to the dom element, right now it is only used by the framework to draw the composing underline (should be a separate issue).

I think the fix for this should be in the framework, we can add the shift + arrow left/right to the web disabling shortcuts here

  const SingleActivator(LogicalKeyboardKey.arrowLeft, shift: true):
      const DoNothingAndStopPropagationTextIntent(),
  const SingleActivator(LogicalKeyboardKey.arrowRight, shift: true):
      const DoNothingAndStopPropagationTextIntent(),

I tried this out and it seems to match the behavior I am observing in html's native TextArea.

@Renzo-Olivares
Thanks also for clarifying the root cause!

Because I hadn't noticed _webDisablingTextShortcuts, I thought it was correct not to call setSelectionRange while converting with the (Japanese) IME. It certainly seems to be a more suitable modification for flutter web to deal with on the framework side.

Adding 4 patterns, left and right, up and down, seems to solve the problem. Would the fix be to add a commit to this PR, or would it be better to open another PR?

Thank you so much for your support. I really appreciate it.