Bug 15903 - When empty <input> is focused, getSelection() exposes shadow tree nodes
Summary: When empty <input> is focused, getSelection() exposes shadow tree nodes
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Forms (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Darin Adler
URL:
Keywords: InRadar
: 28086 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-11-08 14:19 PST by Adam Roben (:aroben)
Modified: 2009-08-10 10:29 PDT (History)
5 users (show)

See Also:


Attachments
testcase (495 bytes, text/html)
2007-11-08 14:22 PST, Adam Roben (:aroben)
no flags Details
testcase for input/textarea elements with selection/range objects (1.59 KB, text/html)
2008-07-23 02:46 PDT, Alex Steitz
no flags Details
patch (15.76 KB, patch)
2009-08-07 18:07 PDT, Darin Adler
mitz: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Roben (:aroben) 2007-11-08 14:19:42 PST
When an empty <input> element is focused, window.getSelection().getRangeAt(0).startContainer returns an HTMLDivElement. I believe this is the HTMLInnerTextField element we put in the shadow tree. We should be returning the HTMLInputElement itself, not this shadow child.
Comment 1 Adam Roben (:aroben) 2007-11-08 14:22:41 PST
Created attachment 17125 [details]
testcase
Comment 2 Alexey Proskuryakov 2007-11-08 23:48:03 PST
What should we return if the INPUT is not empty?

Firefox seems to behave differently - it returns last selection outside INPUT (such as (BODY, 0) - (BODY, 0)) or raises an exception because of not being able to execute getRange(), depending on some conditions that aren't clear to me.
Comment 3 Adam Roben (:aroben) 2007-11-09 08:14:14 PST
(In reply to comment #2)
> What should we return if the INPUT is not empty?
> 
> Firefox seems to behave differently - it returns last selection outside INPUT
> (such as (BODY, 0) - (BODY, 0)) or raises an exception because of not being
> able to execute getRange(), depending on some conditions that aren't clear to
> me.

I guess we'll have to test other browsers as well. I only mentioned the empty case here because it was clearly wrong.
Comment 4 Alex Steitz 2008-07-23 02:44:20 PDT
I found out that this problem affects any input/textarea element whether empty or not.

I also encountered problems with the "anchorNode" and "focusNode" properties of the selection object. These properties as well as the "startContainer" and the "endContainer" are returning a DIV element as parentNode of the selected text node.

I've attached a simple testcase to demonstrate this behaviour.
Comment 5 Alex Steitz 2008-07-23 02:46:56 PDT
Created attachment 22445 [details]
testcase for input/textarea elements with selection/range objects
Comment 6 Eric Seidel (no email) 2009-01-30 15:42:33 PST
Does it return the parent div, or the shadow node?  If it's the shadow node, this will go away when Ojan's patch to remove shadow nodes on <input> elements is finished.
Comment 7 Alex Steitz 2009-02-02 00:55:17 PST
> Does it return the parent div, or the shadow node?  If it's the shadow node,
> this will go away when Ojan's patch to remove shadow nodes on <input> elements
> is finished.
No, the problem is (as you can see at attached test) that the result is a DIV element with the text node inside, but the INPUT/TEXTAREA element is gone.

The result should be 

--snip--
<div>
  <input id="a" value="test input"/>
</div>
--snip--

but it returns

--snip--
<div>
    test input
</div>
--snip--

Same issue is also true for the TEXTAREA element.
Comment 8 Alexey Proskuryakov 2009-07-29 16:47:42 PDT
<rdar://problem/7103776>
Comment 9 Darin Adler 2009-08-07 18:00:08 PDT
*** Bug 28086 has been marked as a duplicate of this bug. ***
Comment 10 Darin Adler 2009-08-07 18:07:23 PDT
Created attachment 34353 [details]
patch
Comment 11 Darin Adler 2009-08-10 10:29:32 PDT
http://trac.webkit.org/changeset/46982