Closed
Bug 151249
Opened 22 years ago
Closed 20 years ago
Middle click does nothing on Mac OS X
Categories
(Core :: XUL, defect, P2)
Tracking
()
VERIFIED
FIXED
mozilla1.8alpha6
People
(Reporter: jan.h.d, Assigned: brion)
References
Details
(Keywords: relnote)
Attachments
(1 file, 5 obsolete files)
(deleted),
patch
|
mikepinkerton
:
review+
sfraser_bugs
:
superreview+
asa
:
approval-aviary-
|
Details | Diff | Splinter Review |
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.
Comment 3•22 years ago
|
||
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
*** Bug 161214 has been marked as a duplicate of this bug. ***
Comment 8•21 years ago
|
||
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.
Comment 9•21 years ago
|
||
this bug still exists in firefox .8. Using OS 10.3, microsoft wheel mouse.
Comment 10•21 years ago
|
||
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?
Comment 11•21 years ago
|
||
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! :)
Comment 12•21 years ago
|
||
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.
Comment 13•21 years ago
|
||
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.
Assignee | ||
Comment 14•20 years ago
|
||
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.
Comment 15•20 years ago
|
||
(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.
Assignee | ||
Comment 16•20 years ago
|
||
> 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.
Assignee | ||
Comment 17•20 years ago
|
||
Cleaned up earlier patch: removed debugging output and adjusted coding style to match the surrounding module a little more.
Assignee | ||
Updated•20 years ago
|
Attachment #147388 -
Attachment is obsolete: true
Comment 18•20 years ago
|
||
(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+
Comment 19•20 years ago
|
||
(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."
Comment 20•20 years ago
|
||
(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
Assignee | ||
Comment 21•20 years ago
|
||
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. :)
Assignee | ||
Comment 22•20 years ago
|
||
(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);
Assignee | ||
Updated•20 years ago
|
Attachment #147464 -
Attachment is obsolete: true
Assignee | ||
Comment 23•20 years ago
|
||
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.
Assignee | ||
Updated•20 years ago
|
Attachment #147469 -
Attachment is obsolete: true
Comment 24•20 years ago
|
||
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.
Assignee | ||
Updated•20 years ago
|
Attachment #147533 -
Flags: review?(samir_bugzilla)
Comment 25•20 years ago
|
||
(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
Assignee | ||
Comment 26•20 years ago
|
||
(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
Comment 27•20 years ago
|
||
*** Bug 242813 has been marked as a duplicate of this bug. ***
Comment 28•20 years ago
|
||
(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".
Assignee | ||
Comment 29•20 years ago
|
||
(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)
Assignee | ||
Updated•20 years ago
|
Attachment #147533 -
Flags: review?(samir_bugzilla) → review?(pinkerton)
Comment 30•20 years ago
|
||
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+
Assignee | ||
Updated•20 years ago
|
Attachment #147533 -
Flags: superreview?(blizzard)
Comment 31•20 years ago
|
||
This problem is still present in Firefox 0.9.
Comment 32•20 years ago
|
||
*** Bug 247376 has been marked as a duplicate of this bug. ***
Comment 33•20 years ago
|
||
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.
Assignee | ||
Comment 34•20 years ago
|
||
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)
Assignee | ||
Updated•20 years ago
|
Attachment #147533 -
Flags: superreview?(bryner)
Comment 35•20 years ago
|
||
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?
Comment 36•20 years ago
|
||
*** Bug 159986 has been marked as a duplicate of this bug. ***
Comment 37•20 years ago
|
||
*** Bug 188628 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Flags: blocking-aviary1.0? → blocking-aviary1.0+
Updated•20 years ago
|
Priority: -- → P2
Comment 38•20 years ago
|
||
*** Bug 249859 has been marked as a duplicate of this bug. ***
Comment 39•20 years ago
|
||
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...
Comment 40•20 years ago
|
||
*** Bug 251603 has been marked as a duplicate of this bug. ***
*** Bug 251952 has been marked as a duplicate of this bug. ***
Comment 42•20 years ago
|
||
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.
Comment 43•20 years ago
|
||
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.
Comment 44•20 years ago
|
||
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
Comment 45•20 years ago
|
||
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 46•20 years ago
|
||
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 47•20 years ago
|
||
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+
Comment 48•20 years ago
|
||
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.
Comment 49•20 years ago
|
||
(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)
Assignee | ||
Comment 50•20 years ago
|
||
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".
Assignee | ||
Updated•20 years ago
|
Attachment #147533 -
Attachment is obsolete: true
Comment 51•20 years ago
|
||
can someone check it in?
Assignee | ||
Updated•20 years ago
|
Attachment #154500 -
Flags: superreview?(sfraser)
Assignee | ||
Comment 52•20 years ago
|
||
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 53•20 years ago
|
||
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 54•20 years ago
|
||
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?
Comment 55•20 years ago
|
||
It works fine for me. Could somebody please check it in?
Comment 56•20 years ago
|
||
(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!
Comment 57•20 years ago
|
||
(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...
Comment 58•20 years ago
|
||
(CCing Simon) Simon, can you just write here if the last minor change is ok-for-you? (you have already SRed the patch).
Comment 59•20 years ago
|
||
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.
Assignee | ||
Comment 60•20 years ago
|
||
(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 61•20 years ago
|
||
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?
Updated•20 years ago
|
Whiteboard: [have patch]
Assignee | ||
Comment 62•20 years ago
|
||
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 63•20 years ago
|
||
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+
Comment 64•20 years ago
|
||
(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.
Updated•20 years ago
|
Attachment #154500 -
Flags: superreview?(sfraser)
Comment 65•20 years ago
|
||
*** Bug 259346 has been marked as a duplicate of this bug. ***
Comment 66•20 years ago
|
||
Does this have even the slightest hope of making it into 1.0? -Z
Comment 67•20 years ago
|
||
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.
Comment 68•20 years ago
|
||
I just installed 1.0PR, and tbis bug is still not fixed. I do have browser.tabs.opentabfor.middleclick set to true.
Updated•20 years ago
|
Flags: blocking-aviary1.0mac? → blocking-aviary1.0mac+
Comment 69•20 years ago
|
||
bryner, the patch has been already SRed earlier, may you have a look?
Comment 70•20 years ago
|
||
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.
Comment 71•20 years ago
|
||
Works perfectly for me too.
Comment 73•20 years ago
|
||
*** Bug 261262 has been marked as a duplicate of this bug. ***
Comment 74•20 years ago
|
||
*** Bug 262763 has been marked as a duplicate of this bug. ***
Comment 75•20 years ago
|
||
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?
Comment 76•20 years ago
|
||
(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.
Comment 77•20 years ago
|
||
(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 78•20 years ago
|
||
Comment on attachment 157220 [details] [diff] [review] Carbon events hack, error handling tweaks back to sfrsr
Attachment #157220 -
Flags: superreview?(bryner) → superreview?(sfraser)
Updated•20 years ago
|
Attachment #157220 -
Flags: superreview?(sfraser) → superreview+
Updated•20 years ago
|
Attachment #157220 -
Flags: approval-aviary?
Comment 79•20 years ago
|
||
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 80•20 years ago
|
||
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+
Comment 81•20 years ago
|
||
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.
Updated•20 years ago
|
Whiteboard: [have patch] → [have patch] - ready to land
Comment 82•20 years ago
|
||
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?
Comment 83•20 years ago
|
||
*** Bug 266609 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 84•20 years ago
|
||
(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 85•20 years ago
|
||
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-
Comment 86•20 years ago
|
||
*** Bug 269013 has been marked as a duplicate of this bug. ***
Comment 87•20 years ago
|
||
Actually it does work in Firefox 1.0 ?
Comment 88•20 years ago
|
||
(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).
Comment 89•20 years ago
|
||
>>it does work in Firefox 1.0<<
No, it does not.
Comment 90•20 years ago
|
||
*** Bug 270259 has been marked as a duplicate of this bug. ***
Comment 91•20 years ago
|
||
*** Bug 270544 has been marked as a duplicate of this bug. ***
Comment 92•20 years ago
|
||
(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.
Comment 93•20 years ago
|
||
Javier, can you please check it in (but note comment 79)? Thanks.
Whiteboard: [have patch] - ready to land → ready to land
Updated•20 years ago
|
Assignee: bugs → brion
Comment 94•20 years ago
|
||
moving blocking-aviary1.0mac+ bugs to Firefox1.1 and Mozilla 1.8a6 Target Milestones.
Target Milestone: --- → mozilla1.8alpha6
Blocks: majorbugs
Comment 95•20 years ago
|
||
*** Bug 272687 has been marked as a duplicate of this bug. ***
Comment 96•20 years ago
|
||
So is anyone going to check this patch in? It's still not in the latest trunk or aviary branches.
Comment 97•20 years ago
|
||
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!
Comment 98•20 years ago
|
||
(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.
Comment 99•20 years ago
|
||
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.
Comment 100•20 years ago
|
||
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.
Comment 101•20 years ago
|
||
Checked in to trunk.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Updated•20 years ago
|
Status: RESOLVED → VERIFIED
Comment 102•20 years ago
|
||
Thanks guys for fixing this. Firefox is now my primary browser on Mac OS X - at last :-) Best regards Mark
Updated•20 years ago
|
Flags: blocking-aviary1.0mac+
Flags: blocking-aviary1.0-
Whiteboard: ready to land
Comment 103•20 years ago
|
||
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! :)
Comment 104•20 years ago
|
||
so does this mean firefox 1.1 will have middle click?
Comment 105•20 years ago
|
||
(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.
Comment 106•20 years ago
|
||
*** Bug 277016 has been marked as a duplicate of this bug. ***
Comment 107•20 years ago
|
||
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.
Comment 108•20 years ago
|
||
This fix also caused bug 277837, just as predicted (comment 59)
Comment 109•20 years ago
|
||
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.
Comment 110•20 years ago
|
||
(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.
Updated•20 years ago
|
Summary: Middle click on link does nothing on Mac OS X → Middle click does nothing on Mac OS X
Comment 111•20 years ago
|
||
*** Bug 290606 has been marked as a duplicate of this bug. ***
Comment 112•19 years ago
|
||
*** Bug 293361 has been marked as a duplicate of this bug. ***
Comment 113•19 years ago
|
||
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?
Comment 114•19 years ago
|
||
(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
Comment 115•19 years ago
|
||
*** Bug 296765 has been marked as a duplicate of this bug. ***
Comment 116•19 years ago
|
||
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+
Comment 117•19 years ago
|
||
(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!
Comment 118•19 years ago
|
||
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.
Comment 119•19 years ago
|
||
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?
Assignee | ||
Comment 120•19 years ago
|
||
(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.
Comment 121•19 years ago
|
||
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.
Comment 122•19 years ago
|
||
(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.
Description
•