Last Comment Bug 674820 - input/textarea.selectionStart/selectionEnd/selectionDirection should not require the presence of a frame
: input/textarea.selectionStart/selectionEnd/selectionDirection should not requ...
Status: RESOLVED FIXED
: html5
Product: Core
Classification: Components
Component: DOM: Core & HTML (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla8
Assigned To: :Ehsan Akhgari (in Taipei, laggy response time)
:
: Andrew Overholt [:overholt]
Mentors:
http://www.whatwg.org/specs/web-apps/...
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-07-27 22:45 PDT by :Ehsan Akhgari (in Taipei, laggy response time)
Modified: 2011-08-05 08:51 PDT (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Patch (v1) (35.47 KB, patch)
2011-07-29 14:41 PDT, :Ehsan Akhgari (in Taipei, laggy response time)
bzbarsky: review+
Details | Diff | Splinter Review

Description User image :Ehsan Akhgari (in Taipei, laggy response time) 2011-07-27 22:45:58 PDT
"All elements to which this API applies have either a selection or a text entry cursor position at all times (even for elements that are not being rendered). User agents should follow platform conventions to determine their initial state."

We currently rely on frames to get these values.  We should start caching them on the content node instead.
Comment 1 User image :Ms2ger (⌚ UTC+1/+2) 2011-07-28 02:16:39 PDT
Bug 674484?
Comment 2 User image Mounir Lamouri (:mounir) 2011-07-28 12:36:09 PDT
Seems indeed to be a dup of bug 674484.
Comment 3 User image :Ehsan Akhgari (in Taipei, laggy response time) 2011-07-29 08:49:45 PDT
No, not at all.  The selection is still retrieved from layout, and in order not to depend on the layout, we need to cache the offsets when we don't have a frame (I have a patch for that).

Bug 674484 is about moving the code around.  That would make things cleaner, but shouldn't have any behavioral effects.
Comment 4 User image :Ehsan Akhgari (in Taipei, laggy response time) 2011-07-29 14:41:17 PDT
Created attachment 549475 [details] [diff] [review]
Patch (v1)
Comment 5 User image Boris Zbarsky [:bz] (still a bit busy) 2011-07-29 20:07:24 PDT
Comment on attachment 549475 [details] [diff] [review]
Patch (v1)

r=me, but maybe we should look into a common superclass for input and textarea?  They're duplicating more and more logic....
Comment 6 User image :Ehsan Akhgari (in Taipei, laggy response time) 2011-08-04 06:19:57 PDT
(In reply to comment #5)
> Comment on attachment 549475 [details] [diff] [review] [diff] [details] [review]
> Patch (v1)
> 
> r=me, but maybe we should look into a common superclass for input and
> textarea?  They're duplicating more and more logic....

The thing which kind of disgusts me about nsHTMLInputElement is that it has to deal with both text and non-text input types, but yes, I think we should do that.  Filed bug 676519.
Comment 7 User image Marco Bonardo [::mak] 2011-08-05 08:51:05 PDT
http://hg.mozilla.org/mozilla-central/rev/2112b458c8c7

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