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

Status: RESOLVED FIXED

(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 [:sefeng211]]

I'll take a look

Comment 42

[Sean Feng [:sefeng211]]

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.

Comment 43

[Sean Feng [:sefeng211]]

note: the provided test case also doesn't work in Safari.

Comment 44

[Jeff Muizelaar [:jrmuizel]]

window.getSelection() does work with <textarea> in Safari though. <textarea> is what chatgpt.com in bug 1902004 is using. Any reason we shouldn't converge on that behaviour?

Comment 45

[alexander]

A reason would be that converging on broken behavior is not a satisfactory conclusion to a 23 years old bug, thank you.

Comment 46

[Jeff Muizelaar [:jrmuizel]]

alexander, do you consider Safari's behaviour more broken than Firefox's? If so, why?

Comment 47

[Sean Feng [:sefeng211]]

I think there are a two undefined things that preventing us from making any changes.

1. how to use DOM range to represent a text selection is not defined, so we don't know what we to do
2. Gecko uses independent selection objects for each text controls, so the document could have selection ranges outside of the text controls, even if the text control has the focus. Then..what should window.getSelection() return in this case?

And changing these things are not trivial..On the other hand, we are also not adding any efforts to address those, and given we've been receiving webcompat reports, maybe it's the time to make compromises now?

I know Masayuki is aware all these and has been asked many times..Masayuki, thoughts on these things..again?

Comment 48

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

If there is a reasonable way, I don't have any reasons to block to change our code. I think that the document selection can have selection ranges even in the text controls at least internally. However, I don't know about what a11y module does.

Comment 49

[alexander]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #46)

alexander, do you consider Safari's behaviour more broken than Firefox's? If so, why?

My mistake, apparently getSelection works in input in Safari in terms of being able to get the string that's actually selected (toString() returns the selected string). I thought it was suggested to converge on that not working in input, only in textarea.

Comment 50

[Sean Feng [:sefeng211]]

I am looking at what we can do to this bug.

Comment 51

[Sean Feng [:sefeng211]]

Attachment: Bug 85686 - Mimic Chromium's getSelection().toString() behaviour

Comment 52

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c354639dff24
Mimic Chromium's getSelection().toString() behaviour r=masayuki,dom-core,webidl,smaug

Comment 53

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/51298 for changes under testing/web-platform/tests

Comment 54

[Cristina Horotan [:chorotan]]

Backed out for causing multiple dt failures

Backout link

Push with failures

Failure log browser_rules_cycle-color.js & others
Failure log browser_rules_cycle-color.js
Failure log browser_changes_declaration_edit_value.js

Comment 55

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR was closed without merging

Comment 56

[Sean Feng [:sefeng211]]

Updated the patch to fix the failures.

Comment 57

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a3cd9e425585
Mimic Chromium's getSelection().toString() behaviour r=masayuki,dom-core,webidl,smaug

Comment 58

[amarc]

https://hg.mozilla.org/mozilla-central/rev/a3cd9e425585

Comment 59

[amarc]

Backed out for causing mass failures

• Backout link
• Push with failures
• Failure Log

Comment 60

[Sean Feng [:sefeng211]]

I fixed the hang, should be good now.

Going to land this patch again

Comment 61

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b6d5438a7c20
Mimic Chromium's getSelection().toString() behaviour r=masayuki,dom-core,webidl,smaug

Comment 62

[Kagami Rosylight [:saschanaz] (they/them) (OOO until 2025-08-18)]

Wow, 24yrs old bug!

Comment 63

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7ce33b38a71b
Fix for build bustages. CLOSED TREE

Comment 64

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/b6d5438a7c20
https://hg.mozilla.org/mozilla-central/rev/7ce33b38a71b

Comment 65

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 66

[Dianna Smith [:diannaS]]

:sefeng anything here worth mentioning in the 138 release notes? Please nominate if so.

Comment 67

[Sean Feng [:sefeng211]]

It's Nightly only, so I don't think we need an release note.

I've filed bug 1954979 for shipping it.

Comment 68

[Dianna Smith [:diannaS]]

fwiw we support 'nightly-only relnotes' for 3 cycles if needed.

Comment 69

[Sean Feng [:sefeng211]]

Ah okay, I didn't know that. Sure!

Release Note Request (optional, but appreciated)
[Why is this notable]:

• This is only enabled in Nightly.
• The fix here is that window.getSelection().toString() can now return the correct text serialization if the focus in a text control, and even if the focus is not in a text control, we may still return the text serialization of a previous focused text control determined by a heuristic. Blink and webkit has something like this for a long time, the idea is to mimic their behaviour for window.getSelection().toString() specifically.

[Affects Firefox for Android]:

• Same as desktop

[Suggested wording]:
window.getSelection().toString() now correctly returns the text serialization when text is selected in a text control.

[Links (documentation, blog post, etc)]:

Comment 70

[Randell Jesup [:jesup] (needinfo me)]

Great! Thanks Sean!
What are the plans for how to get this to release? It's blocking at least two high-visibility webcompat issues (with chatgpt and gemini)

Comment 71

[Sean Feng [:sefeng211]]

The plan was to let it being tested in Nightly for some time. Since we are at soft code freeze now, I am targeting 139

Comment 72

[Ryan VanderMeulen [:RyanVM]]

Removing the nightly release note in favor of the one from bug 1954979.