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.

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

cc hyatt. Dave, who should have this bug?

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.

(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.

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.

I think anthonyd should get this one.

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

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.

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.

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.

moving to 0.9. anthonyd

setting to p1. anthonyd

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

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

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

setting to mozilla 0.9.1

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

verified dups

Wrongly duped.

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

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

--> kin

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

Bug #88049 might fix this. --pete

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.

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.

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.

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.)

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