85686 - window.getSelection() fails when text selected in a form field

Status: NEW

(Core :: DOM: Selection, defect, P3)

Description

[Colin Brown]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.1) Gecko/20010607
BuildID:    2001060703

When using the document.getSelection() method supported by NS4, the Mozilla
javascript console reports: "Deprecated method document.getSelection() called.
Please use window.getSelection() instead."

window.getSelection works for selected text on the page, but not for text
selected in a form field.


Reproducible: Always
Steps to Reproduce:
Please open the attached testcase, getselection.html

Actual Results:  getselection() returns nothing when only text in a form field
is selected.


Expected Results:  text selected in form field should be returned

Comment 1

[Colin Brown]

Attachment: Test Case

Comment 2

[Boris Zbarsky [:bzbarsky]]

seeing this on linux build 2001-07-15-21 as well.

Comment 3

[Johnny Stenback (:jst)]

Post-mozilla1.0

Comment 4

[Prashant Desale]

SEVERITY = MEDIUM [(1)No Crash, (2)Good functional failure, (3)No Cosmetic 
failure]
VISIBILITY = LOW [(1)Dont see any real website usage. (2)Does not work on NS4.x 
as well as IE. (3)Gets one more point on compliance with adopted techonology 
which  is JS] 

PRIORITY = VISIBILITY * SEVERITY

Hence Priority = p4

adding word "qawanted" because I'm setting this priority on available data & if 
someone feels otherwise then please investigate this more & feel free to change 
this priority.

Comment 5

[Fabian Guisset]

Based on my experience and feedback in the newsgroups, getSelection() not
working in textareas is a Bad Thing (TM) for web developers who are creating
their own text editor using the DOM.
However I realize this is not trivial to fix, far from it, so marking P3 and
resetting target milestone. If you don't like it feel free to reassign to me ;-)

Comment 6

[Jesse Ruderman]

See also bug 88049, [RFE] Support .selectionStart & friends for textareas.

If this bug was to be fixed, what would you expect window.getSelection() to
return?  document.getSelection() returns a string, but window.getSelection()
returns an object from which you can extract DOM ranges.

Comment 7

[Colin Brown]

I guess I'd like window.getSelection() to return the same object for textarea's
as it does for other html elements. In my attached test case, the return value
for window.getSelection() is used in a simple fashion as the argument for the
alert method - if this worked for textarea's, I'd be happy.

Comment 8

[Marcus Campbell]

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

Comment 9

[Thomas Forster]

Of course both document.getSelection() and window.getSelection() doesn't work in
IE as this Browser does not know this method at all. But the additional
Microsoft Syntax document.selection.createRange().text; works in both normal
text and form fields, so the wanted results are possible in IE, not in Mozilla.
For damonstration see Test Case for Bug 139416
http://bugzilla.mozilla.org/show_bug.cgi?id=139416

Comment 10

[Pete Collins (MDG)]

Bug #88049 might fix this.

--pete

Comment 11

[Jesse Ruderman]

Returning part of the DOM of a textarea seems wrong to me because it depends on
textareas being built from Mozilla composer.  What do you do if a page tries to
insert a <strong> node or a paragraph into a textarea?  What if Netscape decides
that the current textareas implementation can't be made not to suck and writes a
simpler one?  What if a spell-checker modifies the DOM of the textarea in a way
the script didn't expect?

People voting for this bug: are you voting because...
- you want to be able to put an HTML editor in a web page? (bug 97284)
- you want to know what text is selected in a textarea and be able to
delete/replace it? (bug 88049, fixed)
- you want to use the same function call to access selected text in a textarea
and elsewhere in the document, because using different functions would require
too much code in the page?
- some other reason?

Comment 12

[Marcus Campbell]

Bug 97284 might be about making HTML (richly / dynamically) editable but isn't
really about making an HTML code editor. I wouldn't say everyone is interested
in WYSIWYG editing.

My interest in getting this fixed is that I, and many other web developers, want
end users to be able to mark up selected text in a textarea through the click of
a few buttons. Simple as that. Some people would use HTML (as with many
weblogging / CMS tools) and others a special tagset (as with many message
boards) but it all needs getSelection to work right.

However you're right about bug 88049. Once it is _actually_ fixed in the builds
(and works across rows) then what I'm looking for with getSelection will be easy
to kludge together on the client-side. Not that this would be ideal, mind.

Unlike comment #4, I'd say visibility on this bug is pretty high, and Mozilla
would see a load of happy campers - on both the developer and user side of
things - if we could fix this.

Comment 13

[Andrew Clover]

> you want to use the same function call to access selected text in a textarea and elsewhere    Yes, but mostly for me it's a standards thing. 88049 being done makes me happy, but a fix that would  allow me to code textarea editing stuff in a way that would work with any future browser with DOM  Range support would make me happier.   

Comment 14

[Jesse Ruderman]

> a fix that would allow me to code textarea editing stuff in a way that would 
> work with any future browser with DOM Range support would make me happier.

window.getSelection() is not part of any standard.  selectionStart and
selectionEnd are more likely to work with future browsers, especially if those
browsers use native widgets or simple XP widgets for <textarea>, or decide like
Opera to not support DOM 2.

Comment 15

[Dan Allen]

Attachment: Example workaround using a "mirror" in which text can be selected

A possible workaround for the time being is to do something like this...it is
gross, but if your idea is to save time for your users when typing in custom
tags, this might be your answer.

Comment 16

[Chris Casciano]

Re: Comment 12 - We have this functionality now as a result of Bug 88049 getting
fixed. See the attached testcase for code samples

Regardless, are we going to extend window.getSelection() to include text
inputs/textareas? And if so how would a situation where there is page text and
form text selected independently?

Comment 17

[Johnny Stenback (:jst)]

Mass-reassigning bugs to [e-mail]

Comment 18

[Martijn Wargers (dead)]

Attachment: select parts of textarea with dom range (not directly visible)

It is possible to select parts of the textarea with the dom range, although
this is not visible in the textarea.
Click on one of the buttons to select a part of the textarea (you will not see
the selection as I told you)
Click on the button: alert(allinstancesofranges)
You can see that you've selected some part of the textarea. 

There seems to be no 'connection' between selection by hand and the dom range.
With .selectionStart and .selectionEnd it would be possible to make that
'connection' (at least partly, because with selectionstart en -end you can only
select one instance).

http://bugzilla.mozilla.org/show_bug.cgi?id=152329#c7
Here I have made some comments, which I think how Mozilla should behave
regarding textarea's.
This bug can be added to that list:
-range objects, the selections in textarea's (which you should see) should be
the same. Changes in the selection by hand should be reflected in the selection
object. Changes in the range objects should be reflected in the selection
visible in the textarea.

Comment 19

[Jon Barnett]

I was helping someone with a JavaScript issue:
They were trying to figure out where the focus has gone as a result of an onblur
event:
<input type="text" onblur="something()" etc.. />
and function something() would find the new active/focused element.
IE has something called activeElement and a property of its event object called
"toElement".  
To try to replicate this in Mozilla, the idea was to:
selection = window.getSelection();
range = selection.getRangeAt(0);
And then manipulate the range to try to find the focused element.  This was not
workable when focus was within a form field (which was the goal).  A couple
hours of plugging at it revealed that this may also be a problem if the focus
(caret) is within a FIELDSET. 

"What if the object attempts to place x inside a textarea"
I would assume that the textarea would contain either the text within those
nodes (such as STRONG) or actually contain the pure HTML: (final dynamic output)
<textarea><strong>See what happens</strong></textarea>

Comment 20

[Yuh-Ruey Chen]

(In reply to comment #14)
> > a fix that would allow me to code textarea editing stuff in a way that would 
> > work with any future browser with DOM Range support would make me happier.
> 
> window.getSelection() is not part of any standard.  selectionStart and
> selectionEnd are more likely to work with future browsers, especially if those
> browsers use native widgets or simple XP widgets for <textarea>, or decide like
> Opera to not support DOM 2.

What he means is that he would like to use DOM 2 range, which is a standard, as
much as possible - that it is better to use some standards, rather than none at all.

Comment 21

[Vladimir Yeryomin]

Also, see bug #317914 - window.getSelection() fails on FF1.5rc1+

Comment 22

[Jesse Ruderman]

http://www.squarefree.com/2006/05/06/finding-the-textarea-selection/ has ideas for workarounds, especially for bookmarklets.

Comment 23

[Daniel O'Connor]

Probably a stupid question; what's stopping this being implemented as (in very bad psuedocode):

window.getSelection().toString() {
   var node = window.getSelection().getRangeAt(0).node;
   //normal case, use dom ranges and text
   if (node.supports(DOMRANGES)) {
       return node.selectedText;
   }

   // specialized case: an input/form control which supports selectionStart, selectionEnd
   if (node.selectionStart && node.selectionEnd && node instanceof FormControl) {
       return node.value.substring(node.selectionStart, node.selectionEnd);
   }

   // something else
   throw Exception("ARRGHS!");
}

Comment 24

[John Karahalis [:openjck]]

Looks like this is happening in the wild:

http://stackoverflow.com/questions/20419515/window-getselection-of-textarea-not-working-in-firefox/20427804

Comment 25

[Andy Earnshaw]

It's worth noting that, since the Selection API properties and methods on <input type="number"> throw an error, there's no longer any way to get the selected text from those elements.  window.getSelection() is a valid workaround in Chrome.

This includes moving the caret too, so a JavaScript-based IME cannot interact with <input type="number"> elements at all.

Comment 26

[Andy Earnshaw]

It's worth noting that, since the Selection API properties and methods on <input type="number"> throw an error, there's no longer any way to get the selected text from those elements.  window.getSelection() is a valid workaround in Chrome.

This includes moving the caret too, so a JavaScript-based IME cannot interact with <input type="number"> elements at all.

Comment 27

[Boris Zbarsky [:bzbarsky]]

> the Selection API properties and methods on <input type="number"> throw an error

That's just a bug, and it's fixed.  See bug 1003741.

Comment 28

[Andy Earnshaw]

(In reply to Boris Zbarsky [:bz] from comment #27)
> > the Selection API properties and methods on <input type="number"> throw an error
> 
> That's just a bug, and it's fixed.  See bug 1003741.

Really? I thought it was intentional, as per the spec on text field selections[1]:

> For input elements, calling these methods while they don't apply[2], and getting or 
> setting these attributes while they don't apply, must throw an InvalidStateError 
> exception. Otherwise, they must act as described below.

The spec defines that, for several input types including <input type="number"> and <input type="email">, an InvalidStateError exception should be thrown.  Chrome introduced this in version 33[3], which broke some automated field formatters.  I thought the NS_ERROR_FAILURE thrown by Gecko was the desired behaviour with an incorrect exception being thrown.

There's also an ongoing discussion about it on the W3 tracker[4].

[1]: http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#textFieldSelection
[2]: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#do-not-apply
[3]: https://code.google.com/p/chromium/issues/detail?id=324360
[4]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24796

Comment 29

[Boris Zbarsky [:bzbarsky]]

Yeah, I think the spec is on crack there and should be fixed.

Comment 30

[Dan Dascalescu]

This bug was reported in 2001. That is FOURTEEN YEARS ago.

Comment 31

[BKDotCom]

My use case:
Latitude / Longitude inputs.   These seem to be ideal candidates for type="number" inputs.
It would also good UI to support the common task of copy/pasting coordinates such as "37.387233, -122.060044" from external sources such as google maps...  paste in "lat, lon" -> simple regex determines that latitude AND longitude were entered...  update the two fields appropriately.

This is currently impossible to do in Firefox (since the pasted value is invalid, input.value = "")

This workaround works in every browser except for firefox:

    input.focus();
    document.execCommand("SelectAll");
    var rawValue = window.getSelection().toString();

Comment 32

[joolschadwick]

So is this

Comment 33

[t.rebours]

Seriously, even if it is spec compliant-ish not to have this behaviour and there is an ongoing debate about it, it is not mentionned anywhere in the MDN documentation!

I checked the getSelection, Selection, Selection.toString(), input, HTMLInputElement articles...

I've just lost 1/2 hour trying to understand what's going on...

It's really time-consuming and tiring to write polyfills to cope with this kind of behaviour.

Comment 34

[zakaru]

Wow guys... this is about more than decade for fixing bug.
Can you do something with this? Writing polyfills for such a basic function is insane :/

Comment 35

[Jan Molnár]

Is there a way to detect a selection/range is contained in a form field, please?

I need to process selected text. I do not mind ignoring the selected text inside form fields,* but if there is a text selected inside them, window.getSelection().anchorNode throws the error. I would like to prevent that error via a detection.

(document.activeElement is not the answer, sometimes I have multiple selections and a different unselected element activated.)

* If I knew the detection I could even use selectionStart to process form fields.

Comment 36

[Wojciech Maj]

I have a function that checks on key press if pressing the key would cause the number input to go beyond maximum length specified. Because Firefox fails to return value on window.getSelection() in this case, the function thinks no text is selected, so if the input has already a value as long as maxLength, it will cancel user's input.

I have literally no way of working around this on Firefox while keeping this as a requirement.

See https://github.com/wojtekmaj/react-time-picker/issues/92

Comment 37

[daniel.lee1ibm]

(In reply to Wojciech Maj from comment #36)

I have a function that checks on key press if pressing the key would cause the number input to go beyond maximum length specified. Because Firefox fails to return value on window.getSelection() in this case, the function thinks no text is selected, so if the input has already a value as long as maxLength, it will cancel user's input.

I have literally no way of working around this on Firefox while keeping this as a requirement.

See https://github.com/wojtekmaj/react-time-picker/issues/92

This looks like the same issue I reported here https://bugzilla.mozilla.org/show_bug.cgi?id=1527627, I have a workaround as:

document.activeElement.value.substring(
  document.activeElement.selectionStart,
  document.activeElement.selectionEnd
)

Comment 38

[spamator]

@daniel.lee1ibm, thanks. I have fight with this bug for 2 hours, till I understand that user use FF... and it simply do not pass any data in getSelection()...

BTW proper description under getSelection() page is only partially solution, cause every user expect that every browser behave exactly the same. So getSelection() should work in input fields, and laterrrr user can find out on https://developer.mozilla.org/en-US/docs/Web/API/Window/getSelection that there is more suitable command for it cause of... and then decide who is right... and how it should look/work.

TLDR I doesn't matter (at start) that chrome is wrong with getSelection(), it should work in FF.

Comment 40

[alexander]

Congratulations, Bug 85686, you can legally buy yourself some beer now 🎉

Comment 41

[Sean Feng [:sefeng]]

I'll take a look

Comment 42

[Sean Feng [:sefeng]]

Just a summary, this is an undefined thing in the spec, so browsers behave differently.

To properly fix this, we need to resolve https://github.com/w3c/selection-api/issues/83 which clarifies the Selection API behaviour when user selects contents inside a <input> or <textarea>. And https://github.com/w3c/selection-api/issues/7 which clarifies the Selection.toString() API.