749560 - modifiers for D&D events

Status: NEW

(Core :: DOM: Events, defect, P5)

Description

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(PTO: 9/8)]

Currently, some D&D events on some platforms don't set correct modifier state.

On Cocoa, APIs don't return correct modifiers during D&D. Is it impossible?

On GTK, karlt thinks that we shouldn't set for some D&D events.

bug 731878 comment 51:

> A prospective destination receiving a drag event does not know how the
> source has interpreted the modifier state.  If the destination actually
> tries to use the modifier state, then it's interpretation will likely be
> in conflict with the interpretation at the source (even if both source and
> destination receive the same modifier state info).

> In the GTK port, the modifier state for NS_DRAGDROP_OVER events currently
> comes from a query issued after the drag message is received from the
> source.  That means that the modifier state does not necessarily match
> the state that the source had when it sent the event.

I think that we should set modifiers always if it's possible because web developers may want to know the modifier state for other purpose (not for drop effect). Web application platform should provide the way for any possibilities.

On the other hand, Cocoa's issue is also serious. If it's impossible, we cannot keep consistency between platforms. That may cause some inconvenience for Mac users.

Even if we don't set modifiers to some D&D event, I think that we should *clear* it in nsPresShell. So, I think that GTK should set the modifier state always.

Comment 1

[Karl Tomlinson (:karlt)]

> Even if we don't set modifiers to some D&D event, I think that we should
> *clear* it in nsPresShell. So, I think that GTK should set the modifier
> state always.

The destination drag events do not derive from mouse events, but from drag messages sent from the source (which do not include modifier information).  If the GTK port were to add modifier information to our internal drag events, it would have to make a special effort to get the modifier information.

This is particularly difficult because the source has grabbed the mouse pointer and the destination will rarely if ever have keyboard focus, so the destination does not get notifications of changes in the modifier state.

If the modifiers state gets cleared in nsPresShell, then there is no point in trying to obtain this information.

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(PTO: 9/8)]

Ah, I see. It happens when we're just a destination... I misunderstood your comment. I need to check how we behave when we're source on Mac.

Comment 3

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.