Re: [whatwg] DragEvent's inherited MouseEvent properties should be available to all drag events
On Wed, 12 Aug 2009, Sebastian Markb�ge wrote: The spec should explicitly specify which MouseEvent properties are available during the various drag events to avoid assumptions. The spec requires them to all be set on all drag events, currently. I thought that this was clear too but apparently it's not clear that they should be set to something useful: https://bugzilla.mozilla.org/show_bug.cgi?id=505521 The specification is only partly input device agnostic. It can't be both totally input device agnostic and inherit MouseEvent. If it's going to inherit MouseEvent it needs to be specified what that means. I've added more text to clarify what it means in the case of the mouse not being used. Apparently it also needs to be clear that the properties SHOULD be set, if a pointing device IS being used. See above conversion on the Mozilla bug. I'd suggest you add something like If there is a relevant pointing device, the attributes should be set to relevant position values for all events in the sequence. - So that the intention is clear and don't have to rely on implicit interpretation. The spec says, of all DND events: the event [...] must have the context information set up [...] with [...] the mouse and key attributes set according to the state of the input devices as they would be for user interaction events. What more can I add? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] DragEvent's inherited MouseEvent properties should be available to all drag events
The spec should explicitly specify which MouseEvent properties are available during the various drag events to avoid assumptions. The spec requires them to all be set on all drag events, currently. I thought that this was clear too but apparently it's not clear that they should be set to something useful: https://bugzilla.mozilla.org/show_bug.cgi?id=505521 The specification is only partly input device agnostic. It can't be both totally input device agnostic and inherit MouseEvent. If it's going to inherit MouseEvent it needs to be specified what that means. I've added more text to clarify what it means in the case of the mouse not being used. Apparently it also needs to be clear that the properties SHOULD be set, if a pointing device IS being used. See above conversion on the Mozilla bug. I'd suggest you add something like If there is a relevant pointing device, the attributes should be set to relevant position values for all events in the sequence. - So that the intention is clear and don't have to rely on implicit interpretation.
Re: [whatwg] DragEvent's inherited MouseEvent properties should be available to all drag events
On Wed, 22 Jul 2009, Sebastian Markb�ge wrote: The spec should explicitly specify which MouseEvent properties are available during the various drag events to avoid assumptions. The spec requires them to all be set on all drag events, currently. This issue is related to whether or not a DragEvent is infact a MouseEvent. It is. The current drag specifies that User agents must, every 350ms (�200ms), perform the following steps in sequence.. It doesn't make sense to trigger this event if nothing has changed based on time alone. There's a lot about this model that doesn't make much sense. I think we're long past that point. :-) All current implementations trigger this sequence faster if the mouse is moving. Effectively treating mouse movements as new drag events. Just like mousemove. IMO, it should be specified that mouse movements triggers a new iteration of this sequence, and that current mouse position should be a part of the event. Until we have a user interaction events specification that says what a mouse movement really is, I don't want to specify anything here that would be detailed in that way. The specification is only partly input device agnostic. It can't be both totally input device agnostic and inherit MouseEvent. If it's going to inherit MouseEvent it needs to be specified what that means. I've added more text to clarify what it means in the case of the mouse not being used. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] DragEvent's inherited MouseEvent properties should be available to all drag events
The spec should explicitly specify which MouseEvent properties are available during the various drag events to avoid assumptions. Gecko currently sets pageX, clientX, screenX etc. to zero on the source node events (drag, dragend). As far as I know there are no known security flaws surrounding this implementation. Browsers allow positioning values outside the browser window on mousemove events during a mousedown + mousemove operation. --- This issue is related to whether or no a DragEvent is infact a MouseEvent. The current drag specifies that User agents must, every 350ms (±200ms), perform the following steps in sequence.. It doesn't make sense to trigger this event if nothing has changed based on time alone. If something moves in front of it or behind it, it may need to be triggered again, but a user agent should be able to decide whether or not that's a possibility. All current implementations trigger this sequence faster if the mouse is moving. Effectively treating mouse movements as new drag events. Just like mousemove. IMO, it should be specified that mouse movements triggers a new iteration of this sequence, and that current mouse position should be a part of the event. The specification is only partly input device agnostic. It can't be both totally input device agnostic and inherit MouseEvent. If it's going to inherit MouseEvent it needs to be specified what that means. --- (This is a repost because the first two was blocked by mod filter, hopefully this doesn't become a double post.)
