[Webkit-unassigned] [Bug 30604] New: make Document.caretRangeFromPoint() works for form control nodes (such as <textarea> or contenteditable iframe)

[bugzilla-daemon at webkit.org]

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

           Summary: make Document.caretRangeFromPoint() works for form
                    control nodes (such as <textarea> or contenteditable
                    iframe)
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: All
        OS/Version: All
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: HTML DOM
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: xji at chromium.org


Created an attachment (id=41528)
 --> (https://bugs.webkit.org/attachment.cgi?id=41528)
test case for <textarea>

One use case is to show a tooltip of the word's definition in your
accept-language when you mouse over the word in a page.
It needs to
1. convert the mouse position to character offset within a node (by
Document.caretRangeFromPoint()), and
2. expand the range to 'word' unit.

It is useful for users, especially users from east asian countries, to read the
word's definition in their own language while browsing the internet.

And it is also userful for users to check the word's definition in their own
language while composing something, such as composing an email. This is why I
am thinking of displaying the word's definition for <textarea> or content
editable iframe. Which needs Document.caretRangeFromPoint() returns the from
control node as the range container node, and the offset as the character
offset within the form control node.

But currently, Document.caretRangeFromPoint() is only allowed to return nodes
in the actual DOM, that a user would be able to get to by traversing from the
root node.

form control nodes are not part of the DOM. Document.caretRangeFromPoint()
cannot return a Range in a them since that Range would not be in the DOM. 


====================== Feedback get from Olli at pettay.fi in
public-webapps at w3.org =====================
Do you really want to expose those (native) anonymous DOM nodes to
web? What should happen if one tries to append them to normal DOM?
Or removes them? Or adds (mutation) event listener to them?

I think we need a bit different kind of API for form controls.

====================  Feedback from mjs at apple.com
==================================================
I think we should consider changing caretRangeFromPoint's return type, if it's
not too late. It's useful to get the caret position inside a text form control,
beyond the immediate use case.

Instead of returning a Range, caretRangeFromPoint could return an object like
this:

interface CaretPosition {
   readonly attribute Node containingNode;
   readonly attribute int offset;
   readonly attribute DOMString offsetKind; // "document" or "control"
}

The (containing)node for the <textarea> would be the one reported (or of the
<input type="text"> or whatever kind of form control it was).

It could have a convenience method for converting a Range too, if that's really
needed (which would give null or something for a control position).


Hit testing isn't cheap - ideally we shouldn't design APIs that make you do it
twice.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.