[Webkit-unassigned] [Bug 265674] New: Updating the caret location in a contenteditable using Selection methods does not cause an update to predictive text

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=265674

            Bug ID: 265674
           Summary: Updating the caret location in a contenteditable using
                    Selection methods does not cause an update to
                    predictive text
           Product: WebKit
           Version: Safari 17
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: UI Events
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: jarod.gowgiel at gmail.com
                CC: wenson_hsieh at apple.com

Steps to reproduce:

* On a device running iOS 17 (real or simulated) open https://codepen.io/JarodG/pen/vYbVveQ
* Using a tap, play around with moving the selection around. Notice that when you move the selection, the "predictive text" and autocorrect bar above the software keyboard is being updated in response to the new selection.
    * For example: placing the caret immediately after the pre-existing word "text" will cause predictive text bar to suggest words like "texting" and "texture"
* Now, tap the button titled "Move selection programmatically"
* Notice: the predictive text bar will keep the same state it had before, and is not updated to reflect the new caret position

Why this matters:

Now that "beforeinput" events are widely available, developers should be able to use these events to create their own bespoke text input handlers. However, on iOS Safari, it's impossible to get reliable behavior from the predictive text bar unless the user is directly interacting with the "contenteditable" div. For software that relies on listening for and consuming keyboard events before they reach the focused input, or those that call "preventDefault" on the "beforeinput" event and handle state changes (including text and selection changes) directly, this bug means that iOS Safari predictive text is permanently out of sync with the actual state of the input.

@wenson_hsieh, I'm including you on the CC list here since you're mentioned in an article I ran into announcing the release of "beforeinput" on Safari (https://webkit.org/blog/7358/enhanced-editing-with-input-events/). The functionality I describe above seems to me like it would be necessary for any web app to properly handle text input specifically for some use cases. I'm also curious if you might have any ideas on workarounds - are there additional events that need to be dispatched for predictive text to update? Are there other standard APIs that should be used to adjust the selection on iOS Safari?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20231201/b51a5168/attachment-0001.htm>