This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
On Mac, a newly created selection is by default neither forward nor backward. See the equivalent text in the HTML spec for input elements.
I don't have a Mac handy for testing, so I don't know how browsers behave on Mac. If anyone wants to tell me how the spec should change to match browsers, please do. Adding an explicit settable selection direction property on the Selection interface would also be useful, of course . . .
Moving Selection-related bugs to editing: see bug 14248, bug 14252.
Selection on Mac is directionless at the beginning. Selection gets a direction when setBaseAndExtent is called on getSelection() or base, extent, focus, or anchor of getSelection() is modified, or selection is extended via arrow keys. See http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#dom-textarea/input-selectiondirection
Moving to Selection API component.
I've fixed this when I ported the specification: http://rniwa.github.io/selection-api.html#dfn-direction "Each selection has a direction, forwards, backwards, or directionless. If the user creates a selection by indicating first one boundary point of the range and then the other (such as by clicking on one point and dragging to another), and the first indicated boundary point is after ([DOM4]) the second, then the corresponding selection must initially be backwards. If the first indicated boundary point is before ([DOM4]) the second, then the corresponding selection must initially be forwards. Otherwise, it must be directionless."