[Webkit-unassigned] [Bug 190083] New: 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

            Bug ID: 190083
           Summary: Contenteditable elements should manage the cursor like
                    other user inputs (form elements)
           Product: WebKit
           Version: Safari Technology Preview
          Hardware: iPhone / iPad
                OS: iOS 12
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: HTML Editing
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: manalagi001 at yahoo.com
                CC: wenson_hsieh at apple.com

This is a problem on iOS, where a soft keyboard can obscure part of the user interface, and the cursor can be hidden from view. In my opinion, since contenteditable elements may be used for user input, they should be treated the same as form elements.

In our email client, we use a <div contenteditable=true> element for composing emails. The problem on iOS is that we need to do complex cursor management which I think we should get for free, because form elements already exhibit the desired behavior.

Without cursor management, when someone is editing our <div contenteditable=true>, the cursor can disappear beneath the soft keyboard. This is unfortunate. If we used a TEXTAREA element instead, we would get automatic cursor management for free. With a TEXTAREA, WebKit is smart enough to keep the cursor in view as the TEXTAREA is edited, even with the soft keyboard in view.

However, we cannot use a TEXTAREA for user input in this case, because composing a rich-text, HTML-based email requires us to insert arbitrary markup-- not just the text input of a TEXTAREA.

Because contenteditable elements can function as inputs, I believe they should be treated by WebKit just like form elements are: when it's focused, it should automatically be brought into view and kept in view as it is edited. 

If the automatic scrolling or zooming are detrimental in some cases, perhaps we should allow for an option to enable or disable this proposed behavior.

-- 
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/04156f5e/attachment-0001.html>