Open Bug 85686 Opened 23 years ago Updated 2 years ago

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

Categories

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

Product:
Core
Component:
DOM: Selection
Type:
defect

Tracking

()

Project Flags:
Webcompat Priority P3

People

(Reporter: bugzilla, Unassigned, NeedInfo)

References

(Depends on 1 open bug)

Details

Attachments

(3 files)

Test Case
(deleted), text/html
Details
Example workaround using a "mirror" in which text can be selected
(deleted), text/html
Details
select parts of textarea with dom range (not directly visible)
(deleted), text/html
Details
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
Attached file Test Case (deleted) —
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
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
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 → ---
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.
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.
*** Bug 139416 has been marked as a duplicate of this bug. ***
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
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?
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.
> 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.
> 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.
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.
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.
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>
(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.
Also, see bug #317914 - window.getSelection() fails on FF1.5rc1+
Attachment #104454 - Attachment description: Example workaround → Example workaround using a "mirror" in which text can be selected
http://www.squarefree.com/2006/05/06/finding-the-textarea-selection/ has ideas for workarounds, especially for bookmarklets.
Depends on: 339400
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
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.
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.
(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.
This bug was reported in 2001. That is FOURTEEN 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();
So is this
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.
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 :/
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.
Component: DOM: Core & HTML → DOM: Selection

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

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

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

Performance Impact: --- → ?
Webcompat Priority: --- → ?
Performance Impact: ? → ---
Webcompat Priority: ? → P3
Severity: normal → S3

I'll take a look

Flags: needinfo?(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.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: