58850 - this.selectionStart is broken in XBL handler for textarea,

Status: RESOLVED FIXED

(Core :: DOM: UI Events & Focus Handling, defect, P1)

Description

[Aaron Leventhal]

In XBL (under id="textfield") I tried

<handler event="keypress"
  action="dump(event.rangeParent.data + '\n' + event.rangeOffset + '\n')" />

rangeParent is giving me what I want - the textfield node.
I arrow around the textfield. However, rangeOffset is always 0. I need this to
be an index into the data where the caret is.

This is needed for accessibility purposes. I'm building a speech output option.

Comment 1

[Aaron Leventhal]

Bijal, maybe we can get someone to peek at this. Then I can at least get
textfields working.

Comment 2

[Peter Trudelle]

cc hyatt. Dave, who should have this bug?

Comment 3

[Akkana Peck]

If the range parent is the text field, then the offset wouldn't be the offset
into the text; that would only be the case if range offset were the text node
inside the anonymous div representing the text field's contents (not the text
field itself).

Seems like what you need is to get the location of the selection inside the text
field -- key events don't have a specific location (do they?) but text fields do
(if they're focused, at least) contain selections, and the selection in the text
field (the location of the caret, if the selection is collapsed) is what the
user probably expects to have spoken.

Comment 4

[Aaron Leventhal]

(I think) in the XBL handler event.target==this  ... corect?

I tried both event.target.selectionStart and this.selectionStart (a propety
defined in XBL as this.inputField.selectionStart). Neither worked. Also, if I
iterate over event.target or this.inputField, there is no selectionStart property.

It would seem like the XBL property that's defined for textfield
"selectionStart" should work. For some reason it doesn't. It tries to reference
this.inputField.selectionStart, and returns a strict Javascript error that the
property is undefined.

Comment 5

[Aaron Leventhal]

Changed the subject line to more accurately reflect the bug.
If I can get a fix for this I'll have something to do for a while.

Comment 6

[Simon Fraser [no longer active]]

I think anthonyd should get this one.

Comment 7

[anthonyd]

Aaron,

Do you think you could get a testcase for me to make sure i'm testing this 
correctly?  Just attach it to the bug report.

thanks,
anthonyd

Comment 8

[Aaron Leventhal]

Anythony,

I did some more testing on this bug the other day, and I figured out that
textfield's selectionStart works, but textarea's does not.

The problem is, textarea uses an html:textarea whereas textfield uses
html:input.Each XBL widget then creates a <property> under <implementation> that
called inputField that points to the HTML widget. They also both create a
selectionStart and selectionEnd property that point to
this.inputField.selectionStart and this.inputfield.selectionEnd. These are
expected to exist in the HTML implementation.

So the bug is really that there is no selectionStart property for textarea,
while there is one for textfield.

Comment 9

[Aaron Leventhal]

Attachment: Replacement for xulBingdings.xml in global toolkit shows bug

Comment 10

[Aaron Leventhal]

The bug attachment with xulBindings.xml uses dump() to show the value of
this.selectionStart everytime a left or right arrow is pressed in a textfield
(with or without multiline="true"). The multiline textfields are implemented by
<binding id="textarea">. Since this inherits from the textfield binding, I only
added the handler to textfield.

Anyway, replace your normal xulBindings.xml with this one, and try using left
and right arrows both in single and multiline textfields. selectionStart will
only be defined for single line ones.

Comment 11

[Simon Fraser [no longer active]]

Yes, selectionStart and selectionEnd don't work for multiline text fields 
(because it's hard to calculate them from content). This is a known problem.

Comment 12

[anthonyd]

moving to 0.9.

anthonyd

Comment 13

[anthonyd]

setting to p1.

anthonyd

Comment 14

[Aaron Leventhal]

The test I tried with Anthony didn't work because we weren't using a xul
textarea, we were testing with html textareas.

Here's a test that shows the bug:
In finddialog.xul, change the textfield to add multiline="true" and height="300"
so it looks like this:
     <textfield id="dialog.findKey" oninput="doEnabling();" multiline="true"
height="300"/>
This will give us a xul textarea to test with.

Now, in xulBindings.xml, in the <handlers> section of the binding with
id="textfield" add the line
  <handler event="keyup" action="dump('caret pos: ' + this.selectionStart +
'\n');" />

Now build and run. You'll notice that as you type in the address bar, the
position dumped to the console is correct, but it isn't correct in the find
dialog when you type. This is because selectionStart works in textfields but not
multiline textareas.

Aaron

Comment 15

[Hixie (not reading bugmail)]

Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.

Comment 16

[anthonyd]

*** Bug 70353 has been marked as a duplicate of this bug. ***

Comment 17

[anthonyd]

setting to mozilla 0.9.1

Comment 18

[anthonyd]

*** This bug has been marked as a duplicate of 48575 ***

Comment 19

[Chad Austin]

verified dups

Comment 20

[Simon Fraser [no longer active]]

Wrongly duped.

Comment 21

[anthonyd]

moving this to 1.0, need to reinvestigate this and also talk with aaronl about 
it.

anthonyd

Comment 22

[Simon Fraser [no longer active]]

This is basically making .selectionStart, .selectionEnd, .textLength work for 
multiline textareas, as they do now for single line inputs.

Comment 23

[rubydoo123]

--> kin

Comment 24

[kinmoz]

Bulk move of mozilla1.0 bugs to mozilla.1.0.1. I will try to pull some of these
back in if I can.

Comment 25

[Pete Collins (MDG)]

Bug #88049 might fix this.

--pete

Comment 26

[kinmoz]

Bulk move of my milestoned bugs to Future in an effort to get my milestone lists
to reflect reality.

I will be pulling this bug back into a milestone when I can.

Comment 27

[Alex Vincent [:WeirdAl]]

For the record, I can confirm comment 25.  Fixing bug 88049 will definitely fix
this bug.

textbox.selectionStart refers directly to textbox.inputField.selectionStart --
and textbox.inputField is a <html:textarea /> element.

In other words, this bug is directly caused by bug 88049, and the severity of
that bug should be adjusted to match.  Either that and/or dupe this bug to bug
88049.

Comment 28

[David McCombs]

This bug appears to be unrelated to 88049.  88049 is FIXED and this one persists.
I'm using 1.3a on Linux and still see the problem.  1.2 on Windows XP also has
the problem.

The specific problem I see is that, once I have a linefeed within the textarea,
selectionStart and selectionEnd properties are wrong, seem to be sort of 'folded
over' to the first paragraph in the textarea.

Comment 29

[Alex Vincent [:WeirdAl]]

Mr. McCombs, please clarify your build.  Do you mean Mozilla 1.3 alpha, a 
nightly which was just released, or a trunk which definitely contained the 
fix?  Build string would be helpful here.

Mozilla 1.3 alpha was released well before bug 88049 was fixed.  
(Unfortunately, I'm away from my own computer at this time and will be for the 
next week or so, so I cannot confirm or deny whether the other bug's fix 
applies here.)

Comment 30

[Alex Vincent [:WeirdAl]]

As I predicted, this bug is FIXED.  Attachment 106596 [details] from bug 88049 in recent
nightly is an HTML textarea testcase.  

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030120