DnD incorrectly cancels right-click (which breaks context-menu on FF3/mac)

[bill]

The DnD code calls dojo.stopEvent() on right-mousedown. It should only call it on left-mousedown.

On FF3 and safari, when pressing the right button on a real mouse (*not on the touchpad*), two events are generated:

• a mousedown event, with evt.button == 2
• a contextmenu event

The actual failure point is in Selector.js in this code:

if(!this.singular && !dojo.dnd.getCopyKeyState(e) && !e.shiftKey && (this.current.id in this.selection)){
	this.simpleSelection = true;
	dojo.stopEvent(e);
	return;
}

The above code shouldn't be running if e.button == 2. Actually, the whole function shouldn't be running if e.button == 2, and probably some other functions too.

Note that on IE, a left-click has e.button == 1, and on FF3/safari e.button == 0, so be careful with how you check.

Due to an apparent firefox bug (or perhaps this is correct behavior?), canceling the right-mousedown event also cancels the context-menu event. Thus, this bug manifests itself by breaking context menus on draggable nodes. (Again though, it only happens on FF3/mac when using a real mouse.)

The test case is attached to #8388. (Try right clicking nodes in the bottom right tree.) Although that test case is against the tree DnD code, the problem exists in the generic DnD code as well.

(Derived from #8388)

[bill]

(In [16624]) Fix issue where Tree's DnD code prevents having context menus on tree nodes.

A mouse press of the right mouse button, when done with a real mouse, on mac, causes both a mousedown event and a contextmenu event. On FF3, calling dojo.stopEvent() on the mousedown event also cancels the contextmenu event.

Even if that weren't an issue, the DnD code shouldn't be doing anything on right-mousedown events.

Left mouse-down has evt.button == 1 or evt.button == 0 depending on IE or FF/safari, but right-mouse always seems to be evt.button == 2, so checking that way.

Fixes #8388, refs #8603 !strict.

[Eugene Lazutkin]

It is a little bit more complex than that. IE uses a bit mask (left = 1, right = 2, middle = 4, or any combination of them), and the rest of the world uses an ordinal (left = 0, middle = 1, right = 2).

Relevant links:

• for IE: ​http://msdn.microsoft.com/en-us/library/ms533544(VS.85).aspx
• the standard: ​http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-MouseEvent

I already had a bug when user by mistake pressed more than 1 button, which led to some unexpected results. We should be careful when fixing it.

[bill]

I see... and perhaps even more complex than that: I'm guessing that IE8 non-quirks mode uses the standard too. Would sure be nice if #3470 was fixed.

Anyway thanks for handling this.

[bill]

On closer inspection, I guess the onkeydown isn't even called on IE, just oncontextmenu, so we don't have to worry about it?

[bill]

PS: In my comment above I meant #3740 not #3470.

[Eugene Lazutkin]

Most probably IE8 uses the IE convention in all modes. At least MS doesn't document any deviations from its old schema.

[Eugene Lazutkin]

Yep, IE8 uses the old IE model for mouse buttons.

[Eugene Lazutkin]

(In [16744]) Reshuffling mouse button processing, !strict, fixes #8603.