Closed Bug 151249 Opened 22 years ago Closed 20 years ago

Middle click does nothing on Mac OS X

Categories

(Core :: XUL, defect, P2)

PowerPC
macOS
defect

Tracking

()

VERIFIED FIXED
mozilla1.8alpha6

People

(Reporter: jan.h.d, Assigned: brion)

References

Details

(Keywords: relnote)

Attachments

(1 file, 5 obsolete files)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.1a) Gecko/20020610
BuildID:    2002061014

When clicking with the middle button on any link in
MacOSX, nothing happens.
I does not matter if you set "open new tab" in preferenses
for middle button.

Reproducible: Always
Steps to Reproduce:
1. Click with the middle button on a link


Actual Results:  Nothing happens,

Expected Results:  A new window with the link (or a new tab depending on how
preferences is set) should pop up.
Jan, this is probably dependent on the configuration of your mouse using its'
own software. Have you checked that? Does it work in other OS X browsers?

What brand of mouse are you using?
URL: Any URL
It is a Pilot Wheel Mouse.  The only other app I have that uses the second
button (and that I know how they are supposed to behave) is XDarvin, and that
works (xterm, xev and so on).  The second button is actually a wheel, so it is
strange that the wheel works in Mozilla.

If I install Logitech beta mouse software for MacOSX, the mouse stops working at
all (it is a beta after all...).  So I don't have any special software for the
mouse.
Might be a dup of bug 106215.
Summary: Middle click on link does nothing on MacOSX → Middle click on link does nothing on Mac OS X
I tried the pref mentioned in 106215, it changed nothing.
I looked around in the source and the reason the mouse wheel works is that there
is explicit code for it in Mozilla.  The reason the third buttons works is that
It apparetly automatically gets remapped to Ctrl+mousebutton, which is what
Mozilla looks for.  However, there is no Mac OS X code in Mozilla that looks at
what mouse button was pressed.
As for comment #10 in 106215 (no support for several buttons in Carbon), for Mac
OS X there is, see
http://developer.apple.com/techpubs/macosx/Carbon/oss/CarbonEventManager/Carbon_Event_Manager/Tasks/Mouse_Events.html

Quote: "Unlike earlier versions of Mac OS, which were limited to a one-button
mouse, Carbon is designed to support multiple mouse buttons. (Theoretically, it
can handle as many as 65,535 buttons, though the most you're likely to encounter
in practice is 3.) The kEventParamMouseButton parameter of a mouse-down or
mouse-up event identifies which button was pressed or released, using one of the
following constants:

typedef UInt16  EventMouseButton;
enum
   {
      kEventMouseButtonPrimary   = 1,
      kEventMouseButtonSecondary = 2,
      kEventMouseButtonTertiary  = 3
   
   }; /* end enum */

On a two- or three-button mouse, the left button is normally considered primary
and the right button secondary, but left-handed users can reverse these settings
as a matter of preference. The middle button on a three-button mouse is always
the tertiary button. "

*** Bug 159177 has been marked as a duplicate of this bug. ***
Middle button isn't enabled by default on non-X11 platforms, but even enabling
it doesn't help. See bug 159177.

Confirmed in 1.1beta.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Depends on: 106692
Blocks: 159986
*** Bug 161214 has been marked as a duplicate of this bug. ***
I know that "me too"-comments aren't very helpful, but I simply can't believe
that this still not working. I'm on Panther using a Microsoft USB mouse and this
doesn't work. For me, this is almost a show stopper. MiddleClick-OpenTab is one
of the main reasons I use Moz on Win. Please, do something about this.
this bug still exists in firefox .8.

Using OS 10.3, microsoft wheel mouse.
Another "me too"; I've checked the prefs, and they are fine.  I'm using a simple
3-button Logitech mouse, with no drivers--it's just OS X handling it.

I've heard other people report it as working, but I don't know their system
details.  Perhaps people who are using enhanced drivers are getting the
functionality of the middle-click, but not those of us letting the system do it?
Hi there,

Can anyone comment on the status of this issue?  This bug was opened in June of
2002, almost 2 years ago, and the middle mouse button is still non-functional on
the Mac OS X version of Firefox 0.8.  Both Camino and Mozilla browsers work
properly on the Mac OS X platform when the middle button is depressed, pehaps a
look at the source of either of these browsers would provide some insight.

Nailing this bug would make a lot of Mac Firefox users happy! :)
This is an incredibly annoying bug and it's impressive that it's gone un-fixed
for this long, especially when Camino which is as I understand it also one of
Mozilla.org's projects has had this working pretty much from the beginning.

In fact, this bug it pretty much single-handedly keeping me on Safari rather
than Firefox which I otherwise prefer.
I did a little research with an eye towards fixing this bug, but this is
non-trival to implement.  It would require rewriting the way all mouse events
are handled on the mac.  There is no way to get any information about the middle
button using the current mouse methods.

Camino is built with Cocoa, not with Carbon/XUL, which is why it works out of
the box.
This is a quick proof of concept hack for handling middle-button clicks via
Carbon Events without rewriting the whole event processing infrastructure.
Middle clicks are transformed into fake command+left click events; this works
for opening new tabs/windows but doesn't necessarily act as expected in
general.

Tested briefly on OS X 10.3.3. May kill your dog and tear pages out of your
favorite books.
(In reply to comment #14)
> Created an attachment (id=147388)
> Quick demo of carbon mouse events to get button info
> 
> This is a quick proof of concept hack for handling middle-button clicks via
...

Hmm.. Before I go through the trouble of building my own copy with this patch...

Will this allow me to use the "middle click anywhere in browser window to load
URL in clipboard"? This is one of my favorite features of Mozilla under Linux,
especially the fact that newlines, spaces, etc. are removed from the URL before
pasting, so you can copy and paste from pretty much anywhere without having to
reformat it in any way.

If this will work after applying this patch, I'm going to start building it
immediately.
> Will this allow me to use the "middle click anywhere in browser window to load
> URL in clipboard"? This is one of my favorite features of Mozilla under Linux,

No, sorry, it just simulates command+left-click.

Middle-click load URL on Linux/Unix seems to be a side effect of the middle-click paste idiom, which is 
peculiar to X11. While kind of neat, it's also _really_ annoying when you _just missed_ middle-clicking 
on a link, particularly if unfamiliar with the paste convention. I wouldn't expect this to be replicated on 
other platforms.
Cleaned up earlier patch: removed debugging output and adjusted coding style to
match the surrounding module a little more.
Attachment #147388 - Attachment is obsolete: true
(In reply to comment #17)
> Created an attachment (id=147464)
> Quick hack simulating cmd+click from middle-click using Carbon event handler

This patch was applied and Firefox was built.
middle-click is working!!

Mac OS X 10.3.3
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; ja-JP; rv:1.8a) Gecko/20040502
Firefox/0.8.0+
(In reply to comment #18)
> (In reply to comment #17)
> > Created an attachment (id=147464)
> > Quick hack simulating cmd+click from middle-click using Carbon event handler
> 
> This patch was applied and Firefox was built.
> middle-click is working!!

Not really.  It only opens middle clicks in new tabs.  The middle click is
supposed to be configurable, allowing links to either open in a new tab or
window, and pasting when in the content/urlbar/boxes.

At the very least, browser.tabs.opentabfor.middleclick should be checked, and if
false, then shift+click should be sent instead of cmd+click.

(In reply to comment #16)
> No, sorry, it just simulates command+left-click.
> 
> Middle-click load URL on Linux/Unix seems to be a side effect of the
middle-click paste idiom, which is 

Actually this is available on Windows also, it's just turned off by default. 
Changing middlemouse.paste to true enables it, but

> peculiar to X11. While kind of neat, it's also _really_ annoying when you
_just missed_ middle-clicking 
> on a link, particularly if unfamiliar with the paste convention. I wouldn't
expect this to be replicated on 
> other platforms.

Yes, it is extremely annoying, but there's an option for that also.  Setting
middlemouse.contentLoadUrl to false disables this "feature."
(In reply to comment #14)
 
> Not really.  It only opens middle clicks in new tabs.  The middle click is
> supposed to be configurable, allowing links to either open in a new tab or
> window, and pasting when in the content/urlbar/boxes.
>

How difficult would it be, code-wise, to have the middle-click handler depicted
in this patch call the same event handler/function that middle-click calls on
other platforms like Linux and Windows?

-Z
Now using the unused (for mouse clicks) message field of EventRecord struct to
pass the button number. It's still a bit of a hack, but middle click now works
"for real" for both opening and closing tabs.

For some reason I have to perform at least one left-click in the Mozilla window
before middle-click will open tabs. Once that single initial click has been
done it seems to work as expected; I have no idea what causes this... not quite
ready for prime time. :)
(In reply to comment #15)
> Will this allow me to use the "middle click anywhere in browser window to load
> URL in clipboard"? This is one of my favorite features of Mozilla under Linux,

As of attachment #147469 [details] [diff] [review], yes it now works! Add to prefs.js:
user_pref("middlemouse.contentLoadURL", true);
user_pref("middlemouse.paste", true);
Attachment #147464 - Attachment is obsolete: true
Fixed the first click (now works if you middle-click before doing any
left-clicks) and added "Middle-click" into the preferences text for tabbed
browsing to match other platforms.
Attachment #147469 - Attachment is obsolete: true
Sweet! Works great!

Is this going to be checked into the trunk officially? People have been waiting
for this fix for a while now...

-Z

(In reply to comment #23)
> Created an attachment (id=147533)
> Carbon events hack, now with initial click and prefs fixed
> 
> Fixed the first click (now works if you middle-click before doing any
> left-clicks) and added "Middle-click" into the preferences text for tabbed
> browsing to match other platforms.

Attachment #147533 - Flags: review?(samir_bugzilla)
(In reply to comment #24)

Apparently, I spoke to soon. While I can middle-click to open new tabs, and even
use autoscroll when I enable it, middle click still doesn't do contentLoadURL.

Is this working for you, Brion? I have both the contentLoadURL and paste prefs
turned on, but it doesn't seem to work. The click is just ignored.

-Z
(In reply to comment #25)
> Apparently, I spoke to soon. While I can middle-click to open new tabs, and even
> use autoscroll when I enable it, middle click still doesn't do contentLoadURL.
> 
> Is this working for you, Brion? I have both the contentLoadURL and paste prefs
> turned on, but it doesn't seem to work. The click is just ignored.

Works for me. I added the two prefs lines in comment #22 to a fresh profile, brought up Mozilla, and 
clicked away...

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a) Gecko/20040505
*** Bug 242813 has been marked as a duplicate of this bug. ***
(In reply to comment #4)
> typedef UInt16  EventMouseButton;
> enum
>    {
>       kEventMouseButtonPrimary   = 1,
>       kEventMouseButtonSecondary = 2,
>       kEventMouseButtonTertiary  = 3
>    
>    }; /* end enum */


Not sure if this comment is unnecessary at this point, but I was just gonna say
that these are deprecated.  You wanna use the MouseChord stuff, either
GetEventParameter() for kEventParamMouseChord from your mouse events in your
Carbon event handlers, or you can also in some contexts also use
GetCurrentEventButtonState() to return a mouse chord.  A mouse chord is a UInt32
with bits enabled for each mouse button that is active.  Bit 0 is mouse button
1, bit 1 is mouse button 2, bit 2 is mouse button 3, etc. up through 32 possible
mouse buttons.  So here's some possible code:

UInt32 mouseButtons;
OSStatus error = GetEventParameter(inEvent, kEventParamMouseChord, typeUInt32,
NULL, sizeof(UInt32), NULL, &mouseButtons);
if (error != noErr)
	mouseButtons = GetCurrentEventButtonState();

if ( (mouseButtons & (1<<2)) )
	CheckOutThisHotMiddleClick();

This example is oblivious to when it isn't or isn't possible to rely on
GetCurrentEventButtonState() or get kEventParamMouseChord, but that's covered in
Apple's docs, I haven't looked at Firefox's code so I don't know the specifics
in its case.

I also just wanted to add that this does work fine with any 3+ button mouse with
Mac OS X out of the box with no special mouse "drivers".
(In reply to comment #28)
> Not sure if this comment is unnecessary at this point, but I was just gonna say
> that these are deprecated.  You wanna use the MouseChord stuff,

Mozilla's event model uses discrete mouse button up/down events which wouldn't really fit with the 
chord info; we need kEventParamMouseButton to find which individual mouse button changed state to 
cause the up/down event being processed, then pass that down to the cross-platform code as 
NS_MOUSE_MIDDLE_DOWN, NS_MOUSE_LEFT_UP etc events. I don't see any sign of this being 
deprecated in the online Carbon docs, either.

Of course, the entire rest of the Mac event handling system is using the deprecated Classic events still... 
(bug 106692)
Attachment #147533 - Flags: review?(samir_bugzilla) → review?(pinkerton)
Comment on attachment 147533 [details] [diff] [review]
Carbon events hack, now with initial click and prefs fixed

r=pink though i'm not sure you need the #if XP_MACOSX any more. we no longer
support os9 at all.
Attachment #147533 - Flags: review?(pinkerton) → review+
Attachment #147533 - Flags: superreview?(blizzard)
This problem is still present in Firefox 0.9.
*** Bug 247376 has been marked as a duplicate of this bug. ***
Since I shouldn't (can't?) do this myself, I'd like to ask this bug be targetted
for 0.12. Seems like an appropriate target. Thanks.
Comment on attachment 147533 [details] [diff] [review]
Carbon events hack, now with initial click and prefs fixed

Somebody needs to commit this thing so it can see wider testing... :)
Attachment #147533 - Flags: superreview?(blizzard)
Attachment #147533 - Flags: superreview?(bryner)
requesting blocking on aviary due to the nature of the bug and the fact that it
has a patch pending SR
Flags: blocking-aviary1.0?
No longer blocks: 159986
*** Bug 159986 has been marked as a duplicate of this bug. ***
*** Bug 188628 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.0? → blocking-aviary1.0+
*** Bug 249859 has been marked as a duplicate of this bug. ***
Any reason this hasn't been reviewed and/or checked in yet? As far as I can
tell, it works; this is a long-standing annoyance for MacOSX Firefox/Mozilla
users and this is a welcome patch...
*** Bug 251603 has been marked as a duplicate of this bug. ***
*** Bug 251952 has been marked as a duplicate of this bug. ***
Hey everyone who sees this!!!

We need to start taking some action.  ALL OF US!  This bug still exists because the team doesn't know 
it's here, and annoying people.

This bug is assigned to Samir Gehani <samir_bugzilla@yahoo.com> which is a bad address.
The QA Contact is pawyskoczka@aol.com which is also a bad address.
The reporter is Jan D. <jan.h.d@swipnet.se> but I can't get any indication that this person is working 
on this either.

None of these people have ever made a single post to this forum.  A solid fix has been posted and 
tested.  We just have to get it noticed.  We must make contact with people higher up the chain.  This is 
a team effort.  Lets do it.
I totally agree. it's absolutely absurd that this isn't fixed yet. Let me try
talking to one of the camino devs to see if he knows who we should be emailing.

(In reply to comment #42)
> Hey everyone who sees this!!!
> 
> We need to start taking some action.  ALL OF US!  This bug still exists
because the team doesn't know 
> it's here, and annoying people.
> 
> This bug is assigned to Samir Gehani <samir_bugzilla@yahoo.com> which is a bad
address.
> The QA Contact is pawyskoczka@aol.com which is also a bad address.
> The reporter is Jan D. <jan.h.d@swipnet.se> but I can't get any indication
that this person is working 
> on this either.
> 
> None of these people have ever made a single post to this forum.  A solid fix
has been posted and 
> tested.  We just have to get it noticed.  We must make contact with people
higher up the chain.  This is 
> a team effort.  Lets do it.
reassign to firefox component to get Ben's attention (hopefully) since this has
a patch
Assignee: samir_bugzilla → firefox
Component: XP Apps → General
Product: Browser → Firefox
QA Contact: pawyskoczka → firefox.general
The bug is not Firefox specific. If you want attention open you favorite IRC
client and attach irc.mozilla.org.
Assignee: firefox → bugs
Component: General → XP Toolkit/Widgets
Flags: blocking-aviary1.0mac?
Product: Firefox → Browser
Comment on attachment 147533 [details] [diff] [review]
Carbon events hack, now with initial click and prefs fixed

smfr, can you sr this?
Attachment #147533 - Flags: superreview?(bryner) → superreview?(sfraser)
Comment on attachment 147533 [details] [diff] [review]
Carbon events hack, now with initial click and prefs fixed

>Index: widget/src/mac/nsMacEventHandler.cpp
>===================================================================
>RCS file: /cvsroot/mozilla/widget/src/mac/nsMacEventHandler.cpp,v
>retrieving revision 1.162
>diff -u -8 -p -r1.162 nsMacEventHandler.cpp
>--- widget/src/mac/nsMacEventHandler.cpp	18 Apr 2004 22:00:27 -0000	1.162
>+++ widget/src/mac/nsMacEventHandler.cpp	3 May 2004 09:35:18 -0000
>@@ -1574,16 +1574,24 @@ PRBool nsMacEventHandler::HandleMouseDow
> 		  // don't allow clicks that rolled up a popup through to the content area.
>       if ( ignoreClickInContent )
>         break;
> 						
> 			nsMouseEvent mouseEvent;
> 			PRUint32 mouseButton = NS_MOUSE_LEFT_BUTTON_DOWN;
> 			if ( aOSEvent.modifiers & controlKey )
> 			  mouseButton = NS_MOUSE_RIGHT_BUTTON_DOWN;
>+#if XP_MACOSX
>+			// We've hacked our events to include the button.
>+			// Normally message is undefined in mouse click/drag events.
>+			if ( aOSEvent.message == kEventMouseButtonSecondary )
>+			  mouseButton = NS_MOUSE_RIGHT_BUTTON_DOWN;
>+			if ( aOSEvent.message == kEventMouseButtonTertiary )
>+			  mouseButton = NS_MOUSE_MIDDLE_BUTTON_DOWN;
>+#endif
> 			ConvertOSEventToMouseEvent(aOSEvent, mouseEvent, mouseButton);

Please fix the weird indenting here (remove tabs in that whole block).


>Index: widget/src/mac/nsMacMessagePump.cpp
>===================================================================

>+#ifdef XP_MACOSX
>+  // To handle middle-button clicks we must use Carbon Events
>+  EventTypeSpec eventTypes[2];
>+  eventTypes[0].eventClass = kEventClassMouse;
>+  eventTypes[0].eventKind  = kEventMouseDown;
>+  eventTypes[1].eventClass = kEventClassMouse;
>+  eventTypes[1].eventKind  = kEventMouseUp;

This is normally written:

const EventTypeSpec eventTypes[] = {
  { kEventClassMouse, kEventMouseDown },
  { kEventClassMouse, kEventMouseUp },
}

>+  
>+  EventHandlerUPP handlerUPP = ::NewEventHandlerUPP(nsMacMessagePump::CarbonMouseHandler);
>+  ::InstallApplicationEventHandler(handlerUPP, 2, eventTypes, (void*)this, NULL);
>+#endif

Then here, rather than hardcoding 2, you can use sizeof(eventTypes) /
sizeof(eventTypes[0]).
I think there's actually a macro in the headers to do this for you.

>+#if XP_MACOSX
>+pascal OSStatus	nsMacMessagePump::CarbonMouseHandler(
>+                   EventHandlerCallRef nextHandler,
>+                   EventRef theEvent, void *userData)
>+{

Weird spacing here. No tabs please.

>+  EventRecord theRecord;
>+  ::ConvertEventRefToEventRecord(theEvent, &theRecord);
>+    
>+  EventMouseButton button;
>+  ::GetEventParameter(theEvent, kEventParamMouseButton, typeMouseButton,
>+                      NULL, sizeof(EventMouseButton), NULL, &button);
>+
>+  // Middle click turns to nullEvent in Classic-style event processing!
>+  if (button == kEventMouseButtonTertiary)
>+  {
>+    UInt32 kind = ::GetEventKind(theEvent);
>+    theRecord.what = (kind == kEventMouseDown) ? mouseDown : mouseUp;
>+  }
>+  
>+  // Classic mouse events don't record the button specifier. The message
>+  // parameter is unused in mouse click events, so let's stuff it there.
>+  // We'll pick it up in nsMacEventHandler::HandleMouseDownEvent().
>+  theRecord.message = (UInt32)button;
>+  
>+  // Process the fake event internally
>+  nsMacMessagePump *pump = (nsMacMessagePump*)userData;
>+  pump->DispatchEvent(PR_TRUE, &theRecord);
>+  return noErr;
>+}
> #endif

My only other question here is whether this affects mouse events for plugins.
Wil this break plugins that want middle-mouse clicks?

Looks OK otherwise.
Attachment #147533 - Flags: superreview?(sfraser) → superreview+
As far as I can tell extensions which use mouse input don't work on the Mac
version anyway. Installing, for example, All-in-one Gestures causes right click
to cease functioning; wheras it works fine on Linux/Windows platforms.
(In reply to comment #47)
> >+  EventHandlerUPP handlerUPP =
::NewEventHandlerUPP(nsMacMessagePump::CarbonMouseHandler);
> >+  ::InstallApplicationEventHandler(handlerUPP, 2, eventTypes, (void*)this,
NULL);
> >+#endif
> 
> Then here, rather than hardcoding 2, you can use sizeof(eventTypes) /
> sizeof(eventTypes[0]).
> I think there's actually a macro in the headers to do this for you.


Yes:  GetEventTypeCount(eventTypes)
Adjusts the event handler setup as per comment #47.

The code style in this module is very inconsistent with respect to indentation,
spacing, and tabs; I've tried my best to stay consistent with the surrounding
code ("do as the Romans do"). My apologies if this version still seems ugly but
I don't think I should be rearranging thousands of lines of code in this patch.
:)

I've also fixed the tabbed browsing preferences to use the correct symbol for
the command key instead of the progammer-jargon "Cmd". If you're not willing to
accept that, please use the platformPreOverlay.dtd diff from attachment #147533 [details] [diff] [review]
which only adds back the word "Middle-click".
Attachment #147533 - Attachment is obsolete: true
can someone check it in?
Attachment #154500 - Flags: superreview?(sfraser)
Re comment #47:
> My only other question here is whether this affects mouse events for plugins.
> Wil this break plugins that want middle-mouse clicks?

After a cursory glance at the plugin API... Platform-specific events are sent
from Moz to the plugin; on Mac this is a Classic-style EventRecord (the kind
that doesn't support middle-click information).

A plugin could I think explicitly detect middle mouse clicks by installing its
own Carbon event handler for mouse events, ignoring any that fall outside of its
frame. The ignored events would fall through to the next handler, which would be
the one we've set for the application that hacks up the event stream for Mozilla
to use. So that shouldn't interfere.

The one behavior change I do see with the current patch is that middle mouse
clicks do get passed to the plugin as mouse clicks instead of being completely
ignored. (Tested with QuickTime plugin.) I'm not sure this is a bad thing, but
it could probably be worked around by hacking the event in a different way.
Comment on attachment 154500 [details] [diff] [review]
Carbon events hack, style adjustments and preferences tweak

you can just move the sr=, there is no real big change here, that demends it
another time.
Comment on attachment 154500 [details] [diff] [review]
Carbon events hack, style adjustments and preferences tweak

Patch seems to carry r+sr...looks ready to go in.
Attachment #154500 - Flags: approval-aviary?
It works fine for me. Could somebody please check it in?
(In reply to comment #53)
> (From update of attachment 154500 [details] [diff] [review])
> you can just move the sr=, there is no real big change here, that demends it
> another time.

I see an r=, but I don't think this patch was ever sr='ed.

I want this patch in too!
(In reply to comment #56)
> (In reply to comment #53)
> > (From update of attachment 154500 [details] [diff] [review])
> > you can just move the sr=, there is no real big change here, that demends it
> > another time.
> 
> I see an r=, but I don't think this patch was ever sr='ed.
> 
> I want this patch in too!

so look again...
(CCing Simon)

Simon, can you just write here if the last minor change is ok-for-you? (you have
already SRed the patch).
Looking at the patch again, it worries me that
nsMacMessagePump::CarbonMouseHandler() always returns noErr (stating that the
event was handled). What if ConvertEventRefToEventRecord() or
GetEventParameter() fail? Are there clicks that we don't want to pass to gecko?
Recall that this carbon event handler will get all mouse up/mouse down events.
(In reply to comment #59)
> Looking at the patch again, it worries me that
> nsMacMessagePump::CarbonMouseHandler() always returns noErr (stating that the
> event was handled). What if ConvertEventRefToEventRecord() or
> GetEventParameter() fail?

It is hypothetically possible for those functions to fail, so I guess I could add a fallback fail-out for that.

> Are there clicks that we don't want to pass to gecko?
> Recall that this carbon event handler will get all mouse up/mouse down events.

As far as I can see nsMacMessagePump::DoMessagePump will get all events of any kind via the Classic 
mechanism and send them to the DispatchEvent() event. This patch just gets certain mouse events 
separately and hands them to that same DispatchEvent(), exactly where they would have gone anyway.

Are there any events that don't go through this path? Do we ever have two separate message pumps 
running separate event loops?
Comment on attachment 154500 [details] [diff] [review]
Carbon events hack, style adjustments and preferences tweak

please don't request approval until you have a fully reviewed patch. thanks.
Attachment #154500 - Flags: approval-aviary?
Whiteboard: [have patch]
Same as previous patch, but rearranged a little to abort with an
eventNotHandledErr in case of unexpected failure of GetEventParameter or
ConvertEventRefToEventRecord as per comment #59.

(In this case the event would be handled or ignored by any other Carbon event
handlers there may be after us in the stack, or by the main classic-style
message loop.)
Attachment #154500 - Attachment is obsolete: true
Comment on attachment 157220 [details] [diff] [review]
Carbon events hack, error handling tweaks

r=pink

Is someone going to fix cocoa widget so camino gets this as well?

asking bryner for sr since smfr is on vacation for 3 weeks.
Attachment #157220 - Flags: superreview?(bryner)
Attachment #157220 - Flags: review+
(In reply to comment #63)
> (From update of attachment 157220 [details] [diff] [review])
> r=pink
> 
> Is someone going to fix cocoa widget so camino gets this as well?

Middle-click has always "just worked" in Camino.  For me at least.
Attachment #154500 - Flags: superreview?(sfraser)
*** Bug 259346 has been marked as a duplicate of this bug. ***
Does this have even the slightest hope of making it into 1.0?

-Z
considering that all other major Mozilla browsers for Mac OS work perfectly
fine, I would think that fixing this for FireFox would be a priority.
I just installed 1.0PR, and tbis bug is still not fixed. I do have
browser.tabs.opentabfor.middleclick set to true.
Flags: blocking-aviary1.0mac? → blocking-aviary1.0mac+
bryner, the patch has been already SRed earlier, may you have a look?
For what it's worth, I've applied the patch to 1.7.2 and 1.7.3 now. I've been
browsing with the patched versions for several weeks now, and am not aware of
any mouse problems caused by the patch. I gave one other fellow the patched
1.7.3 version, and he seems quite happy as well.
Works perfectly for me too.
bryner, please review. 

Flags: blocking-aviary1.0+ → blocking-aviary1.0-
*** Bug 261262 has been marked as a duplicate of this bug. ***
*** Bug 262763 has been marked as a duplicate of this bug. ***
Any chance of a super review? I know the reviewer was switched to bryner because
sfraser was going to be on vacation for a few weeks (which was five weeks ago).
Would this patch get reviewed quicker by sfraser?
(In reply to comment #75)
> Any chance of a super review? I know the reviewer was switched to bryner because
> sfraser was going to be on vacation for a few weeks (which was five weeks ago).
> Would this patch get reviewed quicker by sfraser?

Just my $.02:  This just works in camino because they use cocoa.  Mozilla has
given up supporting OS 9.  The main (only?) reason that carbon exists is to
smooth the transition from OS 9 to OS X.  The creator of this patch calls it a
hack and from what little programming I understand, I agree.  Therefore, I
propose that a better goal than getting this patch in is a goal of porting
Camino's event handler subsystem to mozilla.  If my lack of knowledge in this
area has led my logic astray, I am interested in learning of my error.
(In reply to comment #76)
> The creator of this patch calls it a hack and from what little programming 
> I understand, I agree.  Therefore, I propose that a better goal than getting 
> this patch in is a goal of porting Camino's event handler subsystem to mozilla.

I respectfully disagree.  This bug is currently annoying, and will annoy, many Mac Firefox users.  Middle 
clicking on a link is one of the primary reasons I use Firefox.  Users cannot wait for Firefox's event 
handling to be replaced, which probably not happen for months (maybe years) and definitely will not 
occur before 1.0 ships--it's just too risky.

It is far more practical, IMHO, to integrate this patch now and file a seperate enhancement request for 
Cocoa events.
Comment on attachment 157220 [details] [diff] [review]
Carbon events hack, error handling tweaks

back to sfrsr
Attachment #157220 - Flags: superreview?(bryner) → superreview?(sfraser)
Attachment #157220 - Flags: superreview?(sfraser) → superreview+
Attachment #157220 - Flags: approval-aviary?
Please don't add new #ifdef XP_MACOSX sections in Mac-specific code. We only
support OS X anyway so we actually need to remove some of these ifdef's.
Comment on attachment 157220 [details] [diff] [review]
Carbon events hack, error handling tweaks

a=asa for aviary checkin.
Attachment #157220 - Flags: approval-aviary? → approval-aviary+
Just noticed that this patch is misbehaves when using fast user switching.
Having Firefox open in more than one user and doing a middle click on a link
results in the dock and the top menu to stuck and expose using active corners to
stop working until you do sudo killall WindowServer. Can someone confirm that
behaviour ? I'm using Mac OS X 10.3.5 with the latest software updates.
Whiteboard: [have patch] → [have patch] - ready to land
Comment on attachment 157220 [details] [diff] [review]
Carbon events hack, error handling tweaks

need re-approval now that we're past 1.0 RC. setting back to request.
Attachment #157220 - Flags: approval-aviary+ → approval-aviary?
*** Bug 266609 has been marked as a duplicate of this bug. ***
(In reply to comment #81)
> Just noticed that this patch is misbehaves when using fast user switching.
> Having Firefox open in more than one user and doing a middle click on a link
> results in the dock and the top menu to stuck and expose using active corners to
> stop working until you do sudo killall WindowServer.

Actually I can confirm this, but it's not Firefox-specific: in fact I have the same problems even if I have 
not launched Firefox since booting!

Symptoms I see on the second user to log in:
* Middle-click on link selects link, does not launch it (in both Firefox and Safari)
* JS onmousedown *does* see middle button down events (in both Firefox and Safari)
* JS onmouseup *does not* see middle button up events (in both Firefox and Safari)
* If I add debug statements, I see that the Carbon event handler is *not called* for the middle release 
events, but is called for left and right release and all button down events.
* once a middle-click has been made, the Dock icons' titles do not show when you hover oven them 
(but they function on click)
* once a middle-click has been made, Exposé corners do not function
* After some fiddling with the Exposé corner, the menu bar stopped working (except for the fast user 
switch menu, fortunately!)
* After log-out and log-in, problems continue.
* But the first login session remains fine as long as it is still open.
* Sometimes clicking many times gets it to work.

This is obviously a big problem, but it may be an Apple problem, since I can reproduce it 
with Safari. Yuck... Also 10.3.5 here, with latest greatest updates installed.
Comment on attachment 157220 [details] [diff] [review]
Carbon events hack, error handling tweaks

too late for 1.0
Attachment #157220 - Flags: approval-aviary? → approval-aviary-
*** Bug 269013 has been marked as a duplicate of this bug. ***
Actually it does work in Firefox 1.0 ?
(In reply to comment #87)
> Actually it does work in Firefox 1.0 ?

Are you talking about the 1.0 release? If so, it does *not* work on 1.0 for me
(10.3.6 latest and greatest; logitech wheel mouse; logged in for first time).
>>it does work in Firefox 1.0<<

No, it does not.
*** Bug 270259 has been marked as a duplicate of this bug. ***
*** Bug 270544 has been marked as a duplicate of this bug. ***
(In reply to comment #87)
> Actually it does work in Firefox 1.0 ?

Sorry, but it does not.

I was putting off adding my own post for this bug, but this is the *sole* reason
I do not use Firefox on the Mac (my main machine), and the fix for it seems to
be taking forever (hasn't the bug existed for years now?). I thought it would be
fixed in the release version.

Middle-click tab and middle-click close tab: please add these for the next
release. Essential.
Javier, can you please check it in (but note comment 79)? Thanks.
Whiteboard: [have patch] - ready to land → ready to land
Assignee: bugs → brion
moving blocking-aviary1.0mac+ bugs to Firefox1.1 and Mozilla 1.8a6 Target
Milestones.
Target Milestone: --- → mozilla1.8alpha6
*** Bug 272687 has been marked as a duplicate of this bug. ***
So is anyone going to check this patch in? It's still not in the latest trunk or
aviary branches.
Come on people! FIX IT ALREADY!!! It's being so many months since the patch is
available, but thing is, us Mac users don't like compiling, so please include it
in the default trunks!
(In reply to comment #96)
> So is anyone going to check this patch in? It's still not in the latest trunk or
> aviary branches.

For real!  This bug has been around so long, lets commit the patch.  If it
breaks some obscure thing, then that's a new, less obviously, and less annoying
bug.  But the display of impotence thus far is really making the community look bad.
Would it be easier to improve Camino? I like Camino, but Firefox has the
plug-ins that allow for URL/wildcard based ad-blocking and control over Flash
animations. Presumably the former technology (the URL blocking thing) would be
relatively easy to add.

I know it sounds extreme, but Firefox just feels wierd on OS X if you have three
mouse buttons compared to Safari and Camino. If the Gods of Mozilla really feel
it's not important, presumably concentrating on *the* Mac browser, adding the
features that currently give Firefox an advantage, would be the obvious next step.
Camino isn't cross-platform. Firefox is.

I like using Firefox on MacOS X, Windows, and Linux and having the functionality
and UI be the same....Except for the stinkin' middle mouse button.

I agree that this fix should be checked in already. What's the hold up, anyway?

-Z

(In reply to comment #99)
> Would it be easier to improve Camino? I like Camino, but Firefox has the
> plug-ins that allow for URL/wildcard based ad-blocking and control over Flash
> animations. Presumably the former technology (the URL blocking thing) would be
> relatively easy to add.
> 
> I know it sounds extreme, but Firefox just feels wierd on OS X if you have three
> mouse buttons compared to Safari and Camino. If the Gods of Mozilla really feel
> it's not important, presumably concentrating on *the* Mac browser, adding the
> features that currently give Firefox an advantage, would be the obvious next step.

Checked in to trunk.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Thanks guys for fixing this.

Firefox is now my primary browser on Mac OS X - at last :-)

Best regards
Mark
Flags: blocking-aviary1.0mac+
Flags: blocking-aviary1.0-
Whiteboard: ready to land
Firefox still has other issues on MacOS X (it's still far worse than the Windows
version at the moment), but with having this bug fix, I just wanted to let you
know that it is now my new default browser on Macintosh, too (after already
being the default browser on Windows and Linux). Thank you very much for this
great xmas gift! :)
so does this mean firefox 1.1 will have middle click?
(In reply to comment #104)
> so does this mean firefox 1.1 will have middle click?

The latest nightly builds (since Dec. 17) already do, but yes, Fx 1.1 will as well.

*** Bug 277016 has been marked as a duplicate of this bug. ***
Keywords: relnote
The fix for this bug (which was committed to the trunk on 2004-12-15
or 2004-12-16, and which has appeared in Mozilla 1.8a6 and recent
Mozilla 1.8 and Firefox nightlies) interacts badly with the Java
Embedding Plugin (http://javaplugin.sourceforge.net/).

I'm the Java Embedding Plugin's author.  I've opened bug 278655, which
gives a detailed description of the problem and provides a fix (in the
form of a patch to Mozilla 1.8a6).  Please check it out and test my
fix.  I hope to get it into the trunk in the not too distant future.

This fix also caused bug 277837, just as predicted (comment 59)
I've added Simon Fraser's patch to my fix (at bug 278655).  As far as
I can tell it fixes all issues with the fix for this bug (bug 151249)
that's now in the trunk, but (of course) it needs more testing.

Which raises an issue:  When is Firefox 1.1 supposed to come out?

I don't think the bug 151249 fix that's currently in the trunk should
go into Firefox 1.1 in its current state.  If Firefox 1.1 is going to
come out in the next few days or weeks, maybe the bug 151249 fix
should be pulled from the trunk -- it has known bugs, and there
wouldn't be time to adequately test our fixes for them.

I have no problem with it going into the next Mozilla 1.8 alpha (or
beta) -- which is after all mainly for testing.

(Following up comment #109)

> When is Firefox 1.1 supposed to come out?

I've answered my own question, I think.  The "Firefox 2.0 Roadmap"
says that the target release date for "Deer Park" (i.e. FF 1.1) is
March 2005.  That should (I hope) give us enough time to resolve this
issue without having to take drastic measures -- such as removing this
fix from the trunk.

http://www.mozilla.org/projects/firefox/roadmap.html

While we're on the subject ... I've posted yet another patch (based on
Simon Fraser's latest bug 277837 patch) at bug 278655 that resolves
both that bug and bug 277837, and seems to cover all the bases.
Please take a look at it and test it.

Summary: Middle click on link does nothing on Mac OS X → Middle click does nothing on Mac OS X
*** Bug 290606 has been marked as a duplicate of this bug. ***
*** Bug 293361 has been marked as a duplicate of this bug. ***
How is this fixed?

It still (again) does not work with Firefox 1.0.4 on OS X.

Or should I get a trunk build?
(In reply to comment #113)
> How is this fixed?
> 
> It still (again) does not work with Firefox 1.0.4 on OS X.
> 
> Or should I get a trunk build?

Please read the bug before commenting, ths fix will be available in Firefox 1.1
Blocks: deermac
No longer blocks: majorbugs
*** Bug 296765 has been marked as a duplicate of this bug. ***
I'm using the latest Deer Park nightly and I am still unable to make middle
click work as intended.  I have a Logitech MX Laser Cordless Mouse, which opens
a middle-clicked link in the same window.  My Kensington Mouse-In-A-Box does
nothing when it is middle-clicked.

Both of these mice require their own configuration settings (Kensington
MouseWorks and Logitech Control Center), which may explain why they don't work.
 I have not changed the settings for either mouse.

The default setting for a Logitech middle-click is to "click".  Changing this to
"Advanced Click" and modifying it with an "Open Apple Click" seems to make
Firefox's middle click work as expected.  But is there a way to make it work
otherwise?  And is Firefox the appropriate place to make that change?

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050902
Firefox/1.0+
(In reply to comment #116)
> … I have a Logitech MX Laser Cordless Mouse, which opens
> a middle-clicked link in the same window.  My Kensington Mouse-In-A-Box does
> nothing when it is middle-clicked.
> 
> Both of these mice require their own configuration settings …

I think it is no good idea to do such tests with such mouse-software (or other
things like that) active. Why? Because it is not clear, how this software
manipulates the messages. This kind of problems shuld be resolved for a pure OS X.
You don't need “mouse drivers” in OS X. The Apple way is to give the messages to
the applications and they should handle them. If you like to change this way you
can do so. But I do not believe, FireFox (or other software) should have
workarounds for other software. Make it work and *then* see, if your
mouse-driver has got a problem!
Since there seems to be little chance of a Mozilla Suite 1.8 release in the near
future, is there any chance this could get back-ported to the 1.7.x branch?  I
just verified that it is still not fixed in 1.7.11.

Comment #70 indicates that it shouldn't be much trouble to port the patch to
1.7.x.  Bug 278655 and bug 277837 would need to be ported as well.
I am using the lastest DeerPark trunk as following.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20050920
Firefox/1.6a1


The middle-click works as it should be.  However, command-click does not work on
tabs.  Middle-click on tab closes it but command-click does not.

Is it a related bug? Or should I file another?
(In reply to comment #119)
> The middle-click works as it should be.  However, command-click does not work 
on
> tabs.  Middle-click on tab closes it but command-click does not.

Control-click on a tab doesn't do anything on Firefox in Linux either, so I 
wouldn't expect command-click to do anything on a tab in Mac OS X.
Responding to comment #120.

On Mac OS X, the command-click is supported to be equivalent to middle-click,
similar to control-click as right-click.  Therefore, I expected command-click
works for what supposed to be done by middle click.

Command-click on links does bring the page in a new tab as it does by
middle-click.  However, command-click on tab does not close it as middle-click does.
(In reply to comment #121)
> On Mac OS X, the command-click is supported to be equivalent to middle-click,
> similar to control-click as right-click.

Definitely no! Maybe you got this by installing some kind of „mouse driver“. But this translation is not OS X 
own way. (And I'm not sure, what way the [control]-click is handled: is it mapped to “right mousebutton” 
or is the secondary[!] mouse button maped to [control]-primary?)
You need to log in before you can comment on or make changes to this bug.