Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Getting selectionStart / selectionEnd from a hidden textarea results in an uncaught NS_ERROR_FAILURE

RESOLVED FIXED in mozilla10

Status

()

Core
DOM: Core & HTML
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: Pascal Kriete, Assigned: Ehsan)

Tracking

Trunk
mozilla10
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

6 years ago
Created attachment 565290 [details]
ff_selection_test.html

User Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_7; en-us) AppleWebKit/533.20.25 (KHTML, like Gecko) Version/5.0.4 Safari/533.20.27

Steps to reproduce:

If you try to grab the selectionStart or selectionEnd from a textarea after setting style.display to "none", you get an uncaught NS_ERROR_FAILURE exception.



Expected results:

Other browsers seem to cache the old selection. Tested in FF 5.5, 7, and today's nightly.

Comment 1

6 years ago
Ehsan, don't we store that stuff in the editor state now?
Attachment #565290 - Attachment mime type: text/plain → text/html
The problem here is that in GetSelectionStart/End, we do a GetFormControlFrame which might flush, in which case the frame will go away and we throw.  We need to check for the selection information being cached after doing that too.
Assignee: nobody → ehsan
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Created attachment 565325 [details] [diff] [review]
Patch (v1)
Attachment #565325 - Flags: review?(bzbarsky)

Comment 4

6 years ago
Comment on attachment 565325 [details] [diff] [review]
Patch (v1)

Textarea didn't use to null-check mState.  Should it have, or should that change not be made in this patch?

r=me with that sorted out.
Attachment #565325 - Flags: review?(bzbarsky) → review+
Created attachment 565333 [details] [diff] [review]
Patch (v2)

You're right, the null check is not necessary.
Attachment #565325 - Attachment is obsolete: true
Ahem: Bug 617068
(In reply to Ms2ger from comment #6)
> Ahem: Bug 617068

That's a really cryptic bug, but reading the patch, if all you want to do is to throw NS_ERROR_DOM_INVALID_STATE_ERR when this stuff is called on non-text inputs, then you should really look into building your patch on top of this one.  That patch is incorrect already.  :-)
OS: Mac OS X → All
Hardware: x86 → All
Version: 10 Branch → Trunk
https://hg.mozilla.org/integration/mozilla-inbound/rev/463ad8fec3e5
Flags: in-testsuite+
Target Milestone: --- → mozilla10
https://hg.mozilla.org/mozilla-central/rev/463ad8fec3e5
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.