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

NEW
Unassigned

Status

()

P3
normal
18 years ago
a month ago

People

(Reporter: bugzilla, Unassigned)

Tracking

(Depends on: 1 bug)

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

18 years ago
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
(Reporter)

Comment 1

18 years ago
Posted file Test Case
seeing this on linux build 2001-07-15-21 as well.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows NT → All
Hardware: PC → All
Summary: getSelection fails when text selected in a form field → window.getSelection() fails when text selected in a form field
Post-mozilla1.0
Target Milestone: --- → mozilla1.1

Comment 4

17 years ago
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.
Keywords: qawanted
Priority: -- → P4

Comment 5

17 years ago
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 ;-)
Keywords: qawanted → mozilla1.0
Priority: P4 → P3
Target Milestone: mozilla1.1 → ---

Comment 6

17 years ago
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.
(Reporter)

Comment 7

17 years ago
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

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

Comment 9

17 years ago
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
Bug #88049 might fix this.

--pete

Comment 11

17 years ago
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

17 years ago
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

17 years ago
> 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

17 years ago
> 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

17 years ago
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

16 years ago
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?
Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs
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

15 years ago
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

14 years ago
(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

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

Updated

13 years ago
Attachment #104454 - Attachment description: Example workaround → Example workaround using a "mirror" in which text can be selected

Comment 22

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

Updated

13 years ago
Depends on: 339400

Comment 23

12 years ago
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!");
}


Assignee: general → nobody
QA Contact: desale → general

Comment 25

5 years ago
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

5 years ago
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.
> 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

5 years ago
(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
Yeah, I think the spec is on crack there and should be fixed.

Comment 30

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

Comment 31

3 years ago
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

3 years ago
So is this

Comment 33

2 years ago
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

8 months ago
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

5 months ago
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.
You need to log in before you can comment on or make changes to this bug.