Closed Bug 117589 Opened 23 years ago Closed 8 years ago

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

Categories

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

PowerPC
macOS
defect
Not set
major

Tracking

()

RESOLVED WORKSFORME
mozilla1.5alpha

People

(Reporter: masri, Unassigned)

References

()

Details

(Keywords: platform-parity, regression)

Attachments

(1 file)

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?
-> 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
Target Milestone: --- → Future
major usability regression introduced by you, and marked nsbeta1. you're
futuring this?
Request re-triage. This bug causes context menus to pop up when I try to switch 
mail folders.
Target Milestone: Future → ---
if you want to retarget my bugs, you can work on them.
Assignee: pavlov → sfraser
yeah right
Assignee: sfraser → pavlov
Target Milestone: --- → Future
cc gagan for triage input
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 → ---
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
Try for 0.9.9
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.9
Sequence of events for switching mail folder:

Mouse down
In FireContextClick
[make popup]
In KillClickHoldTimer
In KillClickHoldTimer
Mouse up
Update event
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
  
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. ***
I see this when opening some of the Composer dialogs (I get a context menu).
OS: MacOS X → All
Off to 1.0.
Target Milestone: mozilla0.9.9 → mozilla1.0
It will be hard to convince macusers to test 0.9.9 with this bug.
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!
*** 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. ***
Keywords: mozilla1.0
Yippee! I'm using build 2002031308 and this seems to be fixed.

Thanks!
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.
Bug 107433 provides another means of "fixing" this.
*** Bug 131467 has been marked as a duplicate of this bug. ***
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+
sr=hyatt
Comment on attachment 76107 [details] [diff] [review]
Hacky fix to call StillDown() in nsEventStateManager

He meant it, really
Attachment #76107 - Flags: superreview+
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+
Checked in.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
i think this patch may have broken the mach-o build.  simon: can you take a look?
looks like seawood checked in a fix.
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.  
QA Contact: madhur → rakeshmishra
Verified on the trunk build 2002-04-24-12-trunk on Mac OS X.
Status: RESOLVED → VERIFIED
*** Bug 138620 has been marked as a duplicate of this bug. ***
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 → ---
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.
Could this be related to Bug 157837?
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
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.
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.
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).
QA Contact: rakeshmishra → trix
*** Bug 125804 has been marked as a duplicate of this bug. ***
Keywords: nsbeta1nsbeta1-
Target Milestone: mozilla1.0 → mozilla1.5alpha
*** Bug 294743 has been marked as a duplicate of this bug. ***
MAC OS
OS: All → MacOS X
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
Closed: 22 years ago8 years ago
Resolution: --- → WORKSFORME
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: