Bug 269922 – Add API to programatically manipulate text composition (EditContext)

• Status: NEW
• Component: HTML Editing

Right now, in Safari, on both MacOS and iOS, trying to end a composition state or manipulate it is impossible. 

In our specific scenario, we have a hidden textarea which is focused when the user needs to add some text and has the selection synced programatically based on user action. However, for CJK scenarios, it is impossible to achieve the same behaviour as the textarea has when it is manipulated directly by the user.

I think it would be highly beneficial for different scenarios to be able to have an API that allows a developer to programatically:
- change the composition range
- manipulate undetermined and determined text
- decide when a composition should end 

I've also tried some different approaches to end a composition as it can be seen in the following fiddles:

https://jsfiddle.net/6h93zkf4/1/

https://jsfiddle.net/6h93zkf4/2/

Thanks!

[Radar WebKit Bug Importer]

<rdar://problem/123834175>

[Ryosuke Niwa]

Sounds like this is an ask for EditContext.

Hello,

Indeed it could be linked to the EditContext. Is there a status on your side regarding the implementation of the EditContext API for MacOS/iOS?

Thank you!

[Apolo]

Is EditContext going to be worked on by the WebKit team anytime soon?

[Ryosuke Niwa]

(In reply to Apolo from comment #4)
> Is EditContext going to be worked on by the WebKit team anytime soon?

There is no an active plan as far as I know. I don't think we have major concerns about the design so it's likely just an issue of prioritization. It would help us prioritize if you can tell us your use case / which websites will be impacted by this feature.

[Apolo]

I was working on redoing the IME strategy (and overall textfields inner workings) for https://github.com/JetBrains/compose-multiplatform for Web projects since right now it is using a backing textarea with a lot of extra, difficult to reason and hard to maintain code to make it work as if it was a native textfield (it as a Canvas-based framework). It would allow to have a unified api without weird workarounds for each platform. It would also help "force" Firefox to accelerate their implementation since they too have a positive position but have not prioritised it yet. 
Related code: 
https://github.com/JetBrains/compose-multiplatform-core/blob/jb-main/compose/ui/ui/src/webMain/kotlin/androidx/compose/ui/platform/BackingDomInput.kt
https://github.com/JetBrains/compose-multiplatform-core/blob/jb-main/compose/ui/ui/src/webMain/kotlin/androidx/compose/ui/platform/DomInputStrategy.
https://github.com/JetBrains/compose-multiplatform-core/blob/jb-main/compose/ui/ui/src/webMain/kotlin/androidx/compose/ui/platform/NativeInputEventsProcessor.kt
https://github.com/JetBrains/compose-multiplatform-core/blob/jb-main/compose/ui/ui/src/webMain/kotlin/androidx/compose/ui/platform/WebTextInputService.kt
https://github.com/JetBrains/compose-multiplatform-core/blob/jb-main/compose/ui/ui/src/webMain/kotlin/androidx/compose/ui/window/WebTextInputSession.kt

Hello,

I'm part of the Adobe team. Two of the products (already launched) with millions of monthly users:

- Adobe Express: https://express.adobe.com/
- Firefly boards: https://firefly.adobe.com/boards

We're drawing text on a canvas and EditContext would offer the users a native experience (especially for scenarios related to IME and CJK). We're already using it successfully on Chromium-based browsers.

Thanks!

[Ryosuke Niwa]

Thanks for giving us examples. This will help us prioritize the feature :)