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.

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.

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.

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.

if you want to retarget my bugs, you can work on them.

yeah right

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.

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.

Try for 0.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).

Off to 1.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. ***

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

sr=hyatt

Comment on attachment 76107 [details] [diff] [review] Hacky fix to call StillDown() in nsEventStateManager He meant it, really

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

Checked in.

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.

Verified on the trunk build 2002-04-24-12-trunk on Mac OS X.

*** 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.

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.

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).

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

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

MAC OS

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