Clarify selectstart event behaviour

[mystor]

I'm currently implementing selection events for gecko, and I noticed that the selectstart event documentation currently appears to imply that every time that a user changes the selection, a selectstart event should be fired. This is because of the combination of:

When the user agent is about to associate a new range newRange to the selection in response to a user initiated action, the user agent must fire ([DOM4]) an event with the name selectstart [...]

and

If the user makes any modification to a selection, the user agent must create a new range with suitable start and end of the range ([DOM4]) and associate the selection with this new range (not modify the existing range) [...]

This behavior definitely doesn't agree with chrome's implementation (resizing a selection in a textbox with the arrow keys in chrome, for example, doesn't fire selectstart events).

My best guess at the intention of this is that the selectstart event is intended to fire whenever a selection goes from being empty or collapsed to being non-collapsed. This is what I am currently implementing in Bug 571294. The spec should be updated to clarify what the intent is.

[rniwa]

I've updated the sentence so that now it reads as follows:

When the user agent is about to associate a new range newRange to the selection in response to a user initiated action, the user agent must fire ([DOM4]) an event with the name selectstart, which bubbles and is cancelable, at the node associated with the boundary point of newRange's start prior to changing the selection if the selection was previously empty or the previously associated range was collapsed.

[rniwa]

Please reopen the bug if this change is insufficient.