WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
15903
When empty <input> is focused, getSelection() exposes shadow tree nodes
https://bugs.webkit.org/show_bug.cgi?id=15903
Summary
When empty <input> is focused, getSelection() exposes shadow tree nodes
Adam Roben (:aroben)
Reported
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.
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
View All
Add attachment
proposed patch, testcase, etc.
Adam Roben (:aroben)
Comment 1
2007-11-08 14:22:41 PST
Created
attachment 17125
[details]
testcase
Alexey Proskuryakov
Comment 2
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.
Adam Roben (:aroben)
Comment 3
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.
Alex Steitz
Comment 4
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.
Alex Steitz
Comment 5
2008-07-23 02:46:56 PDT
Created
attachment 22445
[details]
testcase for input/textarea elements with selection/range objects
Eric Seidel (no email)
Comment 6
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.
Alex Steitz
Comment 7
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.
Alexey Proskuryakov
Comment 8
2009-07-29 16:47:42 PDT
<
rdar://problem/7103776
>
Darin Adler
Comment 9
2009-08-07 18:00:08 PDT
***
Bug 28086
has been marked as a duplicate of this bug. ***
Darin Adler
Comment 10
2009-08-07 18:07:23 PDT
Created
attachment 34353
[details]
patch
Darin Adler
Comment 11
2009-08-10 10:29:32 PDT
http://trac.webkit.org/changeset/46982
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug