Opened 13 years ago

Closed 13 years ago

#8603 closed defect (fixed)

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

Reported by: bill Owned by: Eugene Lazutkin
Priority: high Milestone: 1.3
Component: DnD Version: 1.2.3
Keywords: Cc:
Blocked By: Blocking:

Description (last modified by 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 && ( in this.selection)){
	this.simpleSelection = true;

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)

Change History (9)

comment:1 Changed 13 years ago by 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.

comment:2 Changed 13 years ago by bill

Description: modified (diff)

comment:3 Changed 13 years ago by Eugene Lazutkin

Milestone: tbd1.3
Status: newassigned

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:

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.

comment:4 Changed 13 years ago by 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.

comment:5 Changed 13 years ago by 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?

comment:6 Changed 13 years ago by bill

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

comment:7 Changed 13 years ago by Eugene Lazutkin

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

comment:8 Changed 13 years ago by Eugene Lazutkin

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

comment:9 Changed 13 years ago by Eugene Lazutkin

Resolution: fixed
Status: assignedclosed

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

Note: See TracTickets for help on using tickets.