[Webkit-unassigned] [Bug 190083] Contenteditable elements should manage the cursor like other user inputs (form elements)

[bugzilla-daemon at webkit.org]

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

--- Comment #1 from James Alley <manalagi001 at yahoo.com> ---
Another challenge we face which is related, but perhaps deserving of a second bug filing:

Our cursor management utilities can only react to text input-- we cannot react to arrow keys. When a user is navigating a contenteditable element with the arrow keys, keydown events are not generated. 

Thus, while our cursor management utilities are able to react as the user types, generating new lines with character and return char inputs, if the user uses arrow keys (e.g. with a bluetooth keyboard paired with an iPad), we cannot detect the event and reposition the scroll position of the element so that the cursor stays in view.

A third difficulty with custom cursor management? We don't know exactly how high the keyboard is. We can estimate the height, but we are unable to account for user preferences such as: are suggestions turned on? Is the user using a split-keyboard? The former, and perhaps the latter, affects the height of the soft keyboard.

A fourth difficulty is that a soft keyboard may or may not appear, depending on keyboard pairing, and there is no event that we can listen to which tells us if the soft keyboard has been displayed.

These problems make the issue of contenteditable ideally behaving like a TEXTAREA in terms of cursor management is even more important.

-- 
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/20180928/77196f3e/attachment.html>