Mouse click interpreted as hold (opens menu) when response takes more than a second

RESOLVED WORKSFORME

Status

()

Core
Event Handling
--
major
RESOLVED WORKSFORME
16 years ago
2 years ago

People

(Reporter: Adam Masri, Unassigned)

Tracking

({pp, regression})

Trunk
mozilla1.5alpha
PowerPC
Mac OS X
pp, regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
Platform: PowerBook G3/300/192Mb/48Gb, MacOS X 10.1.2
Fizzilla Build: 2001122809

It appears that when clicking on things that take more than a second or so to
display, Mozilla is interpreting this as a mousedown. This seems to be happening
everywhere- I've seen it in Mail & Browser windows so far. Since the time
appears to be an issue, I would say that the slower the Mac, the more likely you
are to see this bug. A nice slow G3 should do just fine.

I can see this occur for example:

1) Open Mail, and click on a folder with more than 1,000 messages in it. That
takes at least a second to display. You'll see the same menu display as you
would if you simply held the mouse down on that folder.

2) Click on a Personal Toolbar folder that has a lot of bookmarks in it. If it
takes longer than a second or so to display, you'll see the pop-up you normally
would if you held the mouse button down on it.

- Adam
ccing pinkerton as someone likely to know who mac-specific stuff like this goes 
to.
Summary: Click interpreted as a mousedown event when event takes more than a second → Click interpreted as a mouse hold event when response takes more than a second
we've had tons of these type of issues since pav changed timers.

any ideas, pav?

Comment 3

16 years ago
-> pinkerton, if you think this needs to get fixed for next release, add
apporpriate keywords and give it to pav or whatever is appropriate.
Assignee: joki → pinkerton
this is the main reason that people are bitching about click-hold being busted
on mac. it's a regression from the timer landing and needs to be fixed before beta.

-> pav.
Assignee: pinkerton → pavlov
Severity: normal → major
Keywords: nsbeta1, pp, regression

Updated

16 years ago
Target Milestone: --- → Future
major usability regression introduced by you, and marked nsbeta1. you're
futuring this?

Comment 6

16 years ago
Request re-triage. This bug causes context menus to pop up when I try to switch 
mail folders.
Target Milestone: Future → ---

Comment 7

16 years ago
if you want to retarget my bugs, you can work on them.
Assignee: pavlov → sfraser

Comment 8

16 years ago
yeah right
Assignee: sfraser → pavlov

Updated

16 years ago
Target Milestone: --- → Future

Comment 9

16 years ago
cc gagan for triage input

Comment 10

16 years ago
I agree that this is a serious enough issue to not wait in the future bucket.
Pav if you need help with this then let's adress that.
Target Milestone: Future → ---

Comment 11

16 years ago
reassigning to simon.  we both feel that this is going to be fixed in the mac 
event code, and I'm not the best person to look at this.  If I can be of any 
help though, let me know.
Assignee: pavlov → sfraser

Comment 12

16 years ago
Try for 0.9.9
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.9

Comment 13

16 years ago
Sequence of events for switching mail folder:

Mouse down
In FireContextClick
[make popup]
In KillClickHoldTimer
In KillClickHoldTimer
Mouse up
Update event

Comment 14

16 years ago
Here's the sequence of events:
 Mouse down
  Prime click-hold timer
  Handle slow operation (e.g. changing mail folders)
  (timer fires somewhere)
 Process PLEvents
  Process click-hold timer
  (make context menu popup)
 Mouse up
  

Comment 15

16 years ago
This bad hack in nsMacMessagePump fixes it:
-  if (mRunning)
+  EventRecord tempEvent;
+  if (mRunning && !::EventAvail(mDownMask | mUpMask | keyDownMask | keyUpMask | 
autoKeyMask, &tempEvent))
     Repeater::DoRepeaters(*anEvent);

but we probably don't want to do that. I don't know what to do here.
*** Bug 115907 has been marked as a duplicate of this bug. ***

Comment 17

16 years ago
I see this when opening some of the Composer dialogs (I get a context menu).
OS: MacOS X → All

Comment 18

16 years ago
Off to 1.0.
Target Milestone: mozilla0.9.9 → mozilla1.0

Comment 19

16 years ago
It will be hard to convince macusers to test 0.9.9 with this bug.

Comment 20

16 years ago
Using: 0.9.9 release on Mac OS X 10.1.3

I agree with Benjamin. I can't even select text off a web page without the
/%&$$%&/ contextual menu popping up. 

I'd prefer to have to hit control while clicking to get the menu to pop up if it
meant that I can actually use Moz daily again.

I have to say, though, that I'm really impressed by the quality of work so far.
In just the last few months we've gotten aqua widgets and great speed
improvements. Thanks to all of you!

Comment 21

16 years ago
*** Bug 125347 has been marked as a duplicate of this bug. ***
*** Bug 130788 has been marked as a duplicate of this bug. ***
*** Bug 129512 has been marked as a duplicate of this bug. ***
*** Bug 131093 has been marked as a duplicate of this bug. ***
*** Bug 131123 has been marked as a duplicate of this bug. ***

Comment 26

16 years ago
Yippee! I'm using build 2002031308 and this seems to be fixed.

Thanks!

Comment 27

16 years ago
Scratch that last comment. It's started again, only with a slightly longer
delay. This is mostly notable in mail as I use IMAP servers.

Cheers,
Jason.

Comment 28

16 years ago
Bug 107433 provides another means of "fixing" this.
*** Bug 131467 has been marked as a duplicate of this bug. ***

Comment 30

16 years ago
Created attachment 76107 [details] [diff] [review]
Hacky fix to call StillDown() in nsEventStateManager

This is the hacky fix for this bug. A better fix might be to move the entire
click-hold timer into the widget code, but that would be much more risky at
this point.
Comment on attachment 76107 [details] [diff] [review]
Hacky fix to call StillDown() in nsEventStateManager

ick. r=pink
Attachment #76107 - Flags: review+

Comment 32

16 years ago
sr=hyatt

Comment 33

16 years ago
Comment on attachment 76107 [details] [diff] [review]
Hacky fix to call StillDown() in nsEventStateManager

He meant it, really
Attachment #76107 - Flags: superreview+

Comment 34

16 years ago
Comment on attachment 76107 [details] [diff] [review]
Hacky fix to call StillDown() in nsEventStateManager

a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #76107 - Flags: approval+

Comment 35

16 years ago
Checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 36

16 years ago
i think this patch may have broken the mach-o build.  simon: can you take a look?

Comment 37

16 years ago
looks like seawood checked in a fix.

Comment 38

16 years ago
Mach-O is compiling OK (CVS pull from this morning), but the build still
exhibits unwanted popups. E.g. in News, when moving scroll bars, or when
selecting text with the mouse in a compose window.  

Updated

16 years ago
QA Contact: madhur → rakeshmishra

Comment 39

16 years ago
Verified on the trunk build 2002-04-24-12-trunk on Mac OS X.
Status: RESOLVED → VERIFIED

Comment 40

16 years ago
*** Bug 138620 has been marked as a duplicate of this bug. ***

Comment 41

16 years ago
Reproduced on build 2002072108, Mac OS 9.2.2. Reopening.

This was great for a while, but then it regressed. I think it caused bug 117369,
for example, which would explain why people could only reproduce that bug on
early (i.e. slow) versions of OS X.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---

Comment 42

16 years ago
Ok, bug 117369 isn't a valid example, since it was filed before the first fix
for this bug. This bug is, however, the reason for the `sometimes' in bug 152443.

Comment 43

16 years ago
Could this be related to Bug 157837?

Comment 44

16 years ago
100-percent-reliable way of reproducing this bug:
1.  Go to <http://www.uxp.de/index2.php>.
2.  Try to select any text in the URI.
Summary: Click interpreted as a mouse hold event when response takes more than a second → Mouse click interpreted as hold (opens menu) when response takes more than a second

Comment 45

16 years ago
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.1b) Gecko/20020722

mpt, I (assuming you meant URL) can reproduce about half the time -- it depends
on cycles, I think.  

If I click and hold on anything for about three-quarters-of-a-second, the
contextual menu pops up.  This is a desired feature for one-button-mouse mac
users, I understand.  BUT, this is particularly annoying when you use the mouse
to re-file an e-mail folder or switch browser tabs while a page is loading (for
example) and the contextual menu pops up unbidden.  It's as if the processor
(Moz?) is too bogged down counting to "1 mississip" waiting to pop up the
contextual menu to do what you are actually telling it to do!  Or perhaps the OS
is counting just fine and Moz is too busy dealing with onclick and onselect stuff.

I would assume that people with slower processors have the most trouble with
this.  I have a 400MHz G3 and it's a problem.  Not a big one, but bothersome.

This comment is purely on a FWIW basis.

Comment 46

16 years ago
Just do away with the contextual auto-****. On Mac OS, contextual menus are
invoked by holding down the control key while clicking with a one-button mouse,
and by clicking the right button on a several-button mouse.

This home brewed stuff is getting increasingly annoying. Whenever the load is
getting above 0.06 or so, atempting to drag a link to another tab opens a god
damn contextual menu instead.

Please follow the Apple UI guidelines, using <ctrl>+click to invoke contextual
menus. If you want home brewed stuff, implement a pref where it can be
explicitly turned on, as in other apps.

Comment 47

16 years ago
Nick, that's bug 107433.

And I have been using click-and-hold since Netscape 1.0 - many years before
ctrl-click was added to the Apple Guidelines. Or before multi-button mice were
officially accepted (they have been used for years obviously). It's a choice
between one-handed operation (click-and-hold or multi-button mice) and two
handed operation (ctrl-click).

Updated

16 years ago
QA Contact: rakeshmishra → trix

Comment 48

15 years ago
*** Bug 125804 has been marked as a duplicate of this bug. ***

Updated

15 years ago
Keywords: nsbeta1 → nsbeta1-

Updated

15 years ago
Target Milestone: mozilla1.0 → mozilla1.5alpha

Comment 49

13 years ago
*** Bug 294743 has been marked as a duplicate of this bug. ***

Comment 50

12 years ago
MAC OS
OS: All → MacOS X

Updated

12 years ago
Assignee: sfraser_bugs → events
Status: REOPENED → NEW
QA Contact: trix → ian
Assignee: events → nobody
QA Contact: ian → events
Cannot reproduce:
Version 	49.0a1
Build ID 	20160527030220
User Agent 	Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:49.0) Gecko/20100101 Firefox/49.0
Status: NEW → RESOLVED
Last Resolved: 16 years ago2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.