Closed
Bug 692520
Opened 13 years ago
Closed 13 years ago
Getting selectionStart / selectionEnd from a hidden textarea results in an uncaught NS_ERROR_FAILURE
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
FIXED
mozilla10
People
(Reporter: pascal.kriete, Assigned: ehsan.akhgari)
Details
Attachments
(2 files, 1 obsolete file)
1.04 KB,
text/html
|
Details | |
8.91 KB,
patch
|
Details | Diff | Splinter Review |
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•13 years ago
|
||
Ehsan, don't we store that stuff in the editor state now?
Assignee | ||
Updated•13 years ago
|
Attachment #565290 -
Attachment mime type: text/plain → text/html
Assignee | ||
Comment 2•13 years ago
|
||
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
Assignee | ||
Comment 3•13 years ago
|
||
Attachment #565325 -
Flags: review?(bzbarsky)
Comment 4•13 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+
Assignee | ||
Comment 5•13 years ago
|
||
You're right, the null check is not necessary.
Attachment #565325 -
Attachment is obsolete: true
Comment 6•13 years ago
|
||
Ahem: Bug 617068
Assignee | ||
Comment 7•13 years ago
|
||
(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. :-)
Updated•13 years ago
|
OS: Mac OS X → All
Hardware: x86 → All
Version: 10 Branch → Trunk
Assignee | ||
Comment 8•13 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/463ad8fec3e5
Flags: in-testsuite+
Target Milestone: --- → mozilla10
Comment 9•13 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/463ad8fec3e5
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•