This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Here's what the current spec says about the initial selection status for textarea elements <http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#dom-textarea/input-setselectionrange>: "User agents should follow platform conventions to determine their initial state." This makes it really hard for web applications to be able to tell what's going to happen when a textarea element is focused. The current Gecko behavior here is that we set the selection to the end of the textarea. The reason that we've historically done that is a by-product of an implementation detail, and it has not been a conscious decision (see https://bugzilla.mozilla.org/show_bug.cgi?id=612129#c18). The current WebKit behavior is that it sets the selection to the beginning of the textarea. The WebKit's code points to https://bugs.webkit.org/show_bug.cgi?id=11746#c15 as a rationale. I personally think that the WebKit behavior is better since it means that the textarea won't scroll when first focused, which seems to be what web authors expect. I'm switching the Gecko behavior to set the selection to the beginning of the textarea too. It would be great if the HTML5 spec specifies this behavior in order to prevent discrepancy between UAs.
FWIW, this bug seem related to bug 11699.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: This still has to be up to the UA, because different platforms have different conventions here. As far as I can tell, the Mac OS X default behaviour with multiline text fields is to put the caret at the start, and the Mac OS X default behaviour for one-line text fields is to select the text field value. On Windows, the platform behaviour for multiline text fields when they are read-only is to put the caret at the start, but for editable text fields, when the control is focused the entire contents are selected and the cursor is put at the end (though it is not scrolled, so if its contents are bigger than the text field, the cursor won't be visible). For single line text fields, the contents are selected when the control is focused.
mass-move component to LC1