39192 - Drag+click (select) interpreted as double-click [MAC]

Status: RESOLVED FIXED

(Core :: DOM: UI Events & Focus Handling, defect, P1)

Description

[Jesse Ruderman]

one two three four

1. Drag from the middle of the word one to the middle of the word three
2. Let go of the mouse button and quickly click it down again

Expected result: selection cleared
Actual result: the word "three" is selected

Comment 1

[Sean Richardson]

Could this be the same problem under the hood as bug 37151, "radio and 
checkboxes process on mouseup regardless of where mousedown originated", M17, 
ASSIGNED? 

Comment 2

[joki (gone)]

this is a result of the new multi-click code.  Reassigning.

Comment 3

[rods (gone)]

Marking as P1, so it is one of the first ones I look at when I can start pulling 
bugs off Future.

The issue is knowing that a drag was down and clearing the double click time.

This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another 
known resource will be working on this bug,or if it blocks your work in some way 
-- please attach your concern to the bug for reconsideration. 

Comment 4

[ckritzer (gone)]

Mass update:  changing qacontact to [e-mail]

Comment 5

[Jesse Ruderman]

The "opposite" bug has been filed as bug 53144.  In that bug, you click first 
and then drag.  In this bug, you drag first and then click.

Comment 6

[Loco]

Updating QA Contact.

Comment 7

[Loco]

Hmmm...this seems terribly annoying but not enough for RTM nomination.  Sorry for 
the spam. -d

Comment 8

[Blake Ross]

Rod, now that it's a new cycle, can we unfuture this (per your 6/22 comment)?

Comment 9

[rods (gone)]

Fixed it, just needed to clear the click counter on mouse moves.

Comment 10

[rods (gone)]

Attachment: patch, fixed bug and cleaned up some of the code

Comment 11

[rods (gone)]

Attachment: lastest patch

Comment 12

[Kevin McCluskey (gone)]

Latest patch looks good.
r=[e-mail]

Comment 13

[Jesse Ruderman]

Rods, does the patch happen to fix bug 47966 as well?

Comment 14

[rods (gone)]

*** Bug 47966 has been marked as a duplicate of this bug. ***

Comment 15

[rods (gone)]

Jesse thanks for pointing out Bug 47966, it is a dup of this bug and is now 
fixed also. Comment from my checkin:

The click counter needs to be zeroed during a drag so a click that happens 
within the threshold of time between the end click of the drag and the beginning 
click of the single click isn't counted like a double click.

The time in between the two which is system dependent and quite long.

Comment 16

[Loco]

Mac issue also, confirmed in Mac 01-18-15.  Not fixed there.

REOPENING.

Comment 17

[Matthew T (active 1999-2002)]

[Clearing fix in hand status, since the fix was checked in but didn't fix it.]

This bug is still happening on Mac OS, what about Windows and Linux?

Comment 18

[Hixie (not reading bugmail)]

Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.

Comment 19

[rods (gone)]

Setting platform to Mac and reassigning to waqar to take a look

Comment 20

[Kevin McCluskey (gone)]

Setting milestone to future

Comment 21

[Madhur Bhatia]

QA contact updated

Comment 22

[Kevin McCluskey (gone)]

bulk reassigning Waqar's bugs to Don.

Comment 23

[Frankie]

2 years later...

This bug still affects Mac OSX release 1.2.1, presumably all.

The severity rating could probably afford to be dialed down a notch or two.

Comment 24

[Mr Israel Steinmetz]

Should this still have the qawanted keyword?

Comment 25

[Andrew Schultz]

Is this still a problem on Mac with recent builds (1.7 or 1.8b)?  It works fine
on linux.

Comment 26

[Jesse Ruderman]

WFM on Windows - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2)
Gecko/20050521 Firefox/1.0+

Comment 27

[Stefan [:stefanh]]

I see this on a recent mac nightly (suite), so this is still an issue on mac.

Comment 28

[Wayne Mery (:wsmwk)]

(Rod in reply to comment #15)
> Jesse thanks for pointing out Bug 47966, it is a dup of this bug and is now 
> fixed also. Comment from my checkin:
> 
> The click counter needs to be zeroed during a drag so a click that happens 
> within the threshold of time between the end click of the drag and the beginning 
> click of the single click isn't counted like a double click.

might help to know which bug and checkin that is.


bug 91693 related?

Comment 29

[Wayne Mery (:wsmwk)]

Kartsen, do you see this and bug 91693?

Comment 30

[Karsten Düsterloh]

This is WFM, but I've got no real mouse, just a touchpad (PowerBook G4), so that doesn't count probably.

Comment 31

[Wayne Mery (:wsmwk)]

Andrew? stefanh?

Comment 32

[Stefan [:stefanh]]

This worksforme on trunk (seamonkey, 10.3.9), but not on 1.8 branch.

Comment 33

[Uri Bernstein]

This was fixed on trunk between 2006-09-28 and 2006-09-29, almost certainly due to bug 326469 (enabling cocoa).