Firefox 4.x middle-click event handling regression with alps touchpad drivers
Michael A. Puls II
WinXP SP3
Alps Touchpad mouse drivers installed
<http://shadow2531.com/opera/alps/AlpsA00.EXE>
ps/2 KME (keymouse) MD-335 optical mouse
Ever since Opera 10.5 came out, there's been a middle-click problem with
that mouse (not necessarily only that mouse) while the Alps touchpad
drivers are installed. Many Opera users have been having trouble with
this. And, scrolling has been broken on the actual touchpad (including on
*modern* laptops with the alps touchpad).
Basically, middle-clicking on a tab won't close the tab and instead,
auto-scroll mode is turned on and you get an auto-scroll cursor. The title
bar also grays out (as if you were middle-clicking on the title bar).
Further, middle-clicking in a page will cause things to go into
auto-scroll mode too like it's supposed to, but moving the mouse up or
down won't scroll the page.
In my research, I've found that when the Alps Touchpad drivers are
installed, when certain applications are open, middle-clicking in Opera
will break and it will break because the WM_MBUTTONDOWN event isn't firing
when you middle-click.
Here are a list of applications being open that cause the problem in Opera:
taskmgr.exe
Media Player Classic Home Cinema
Gvim
The windows charmap program
AbiWord
If any of those programs are open, WM_MBUTTONDOWN won't fire. I can even
confirm with the following code where if any of those programs are open,
middle-clicking in the window area won't close the app.
-------------
#include <windows.h>
const char g_szClassName[] = "myWindowClass";
// Step 4: the Window Procedure
LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
switch(msg)
{
case WM_CLOSE:
DestroyWindow(hwnd);
break;
case WM_DESTROY:
PostQuitMessage(0);
break;
case WM_MBUTTONDOWN:
PostQuitMessage(0);
break;
default:
return DefWindowProc(hwnd, msg, wParam, lParam);
}
return 0;
}
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPSTR lpCmdLine, int nCmdShow)
{
WNDCLASSEX wc;
HWND hwnd;
MSG Msg;
//Step 1: Registering the Window Class
wc.cbSize = sizeof(WNDCLASSEX);
wc.style = 0;
wc.lpfnWndProc = WndProc;
wc.cbClsExtra = 0;
wc.cbWndExtra = 0;
wc.hInstance = hInstance;
wc.hIcon = LoadIcon(NULL, IDI_APPLICATION);
wc.hCursor = LoadCursor(NULL, IDC_ARROW);
wc.hbrBackground = (HBRUSH)(COLOR_WINDOW+1);
wc.lpszMenuName = NULL;
wc.lpszClassName = g_szClassName;
wc.hIconSm = LoadIcon(NULL, IDI_APPLICATION);
if(!RegisterClassEx(&wc))
{
MessageBox(NULL, "Window Registration Failed!", "Error!",
MB_ICONEXCLAMATION | MB_OK);
return 0;
}
// Step 2: Creating the Window
hwnd = CreateWindowEx(
WS_EX_CLIENTEDGE,
g_szClassName,
"The title of my window",
WS_OVERLAPPEDWINDOW,
CW_USEDEFAULT, CW_USEDEFAULT, 240, 120,
NULL, NULL, hInstance, NULL);
if(hwnd == NULL)
{
MessageBox(NULL, "Window Creation Failed!", "Error!",
MB_ICONEXCLAMATION | MB_OK);
return 0;
}
ShowWindow(hwnd, nCmdShow);
UpdateWindow(hwnd);
// Step 3: The Message Loop
while(GetMessage(&Msg, NULL, 0, 0) > 0)
{
TranslateMessage(&Msg);
DispatchMessage(&Msg);
}
return Msg.wParam;
}
-------------
Further, middle-clicking to close the app will work fine *if* the app
isn't focused. So, it's an issue only when the app is focused.
Further, when Media Player Classic is open, middle-clicking a tab in Opera
or the window area in the test app will produce a different kind of
autoscroll cursor, one without up and down arrows, just left and right.
Anyway, although this looks like a mouse driver bug, Firefox 3.x, IE8,
Safari, Notepad++, Foobar, K-Meleon, Midori and Opera 10.10 etc. all work
fine. It's just with Opera 10.5+.
Now, since Opera 10.5 changes the drawing of the UI a lot, I figured it
was just a bug with Opera. This was further supported by Firefox not
having a problem with WM_MBUTTONDOWN not firing.
However, after a while, I noticed that Chrome had this problem too.
Anyway, I was just testing Firefox 4.x and notice that Firefox now has
this problem too. Things still work fine in FF 3.7.
I don't know why Firefox 4.x, Opera 10.5 and Chrome have this problem
while other apps/versions do not, but it has something to do with the
WM_MBUTTONDOWN event handling. For example, if Firefox 3.7 gets a
WM_MBUTTONUP event on a tab without getting a WM_MBUTTONDOWN, things still
work fine, where as with Firefox 4.x, they do not.
I know nothing about Windows API event handling or how the various
browsers handle events in their GUIs, so all I can do is inform you about
this problem.
Finally, if the alps touchpad drivers are not installed and the ms wheel
mouse drivers for example are used for the mouse, everything is fine.
Now, I did file a bug report for Opera, but I guess no one knows anything
about this. Now that it affects Firefox, maybe someone here (or a Chrome
dev passing by) will know what the problem is.
--
Michael
Mike Beltzner
Michael - do you have a bugzilla account? The tail end of this email (the context about Opera is interesting, but ultimately I don't think it helps us debug things) would make a fabulous bug report.
cheers,
mike
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
Philip Chee
> Hm - did we change the way we're handling these mousebutton
> interactions?
>
> Michael - do you have a bugzilla account? The tail end of this email
> (the context about Opera is interesting, but ultimately I don't think
> it helps us debug things) would make a fabulous bug report.
By total coincidence I was recently looking at Bug 216899 -
middle-clicking functions ContentLoadURL and autoscroll conflict.
I don't see anything in the front end that has changed recently though.
> On 2010-07-24, at 10:05 AM, Michael A. Puls II wrote:
>> Further, middle-clicking to close the app will work fine *if* the
>> app isn't focused. So, it's an issue only when the app is focused.
>> Anyway, I was just testing Firefox 4.x and notice that Firefox now
>> has this problem too. Things still work fine in FF 3.7.
Hmm. Focus Manager? Enn?
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
RyanVM
wrote:
Interesting, I'd been seeing this for awhile on my laptop as well.
Nice diagnosis work! I think it started on Firefox trunk builds around
the time that drawing in the title bar was turned on, but don't quote
me on that.
Michael A. Puls II
wrote:
> Hm - did we change the way we're handling these mousebutton interactions?
>
> Michael - do you have a bugzilla account? The tail end of this email
> (the context about Opera is interesting, but ultimately I don't think it
> helps us debug things) would make a fabulous bug report.
Yep, I have a bts account. I'll be glad to file on this later today. I
already filed this for chromium
<http://code.google.com/p/chromium/issues/detail?id=50135> to see what
they think.
--
Michael
Michael A. Puls II
Thanks for the info. It's probably no coincidence that Opera started
having this problem when they switched to drawing the UI with their new
graphics engine (vega) and added support for collapsing the title bar (or
putting tabs in the title bar) when the menu bar is hidden. And, it's
probably no coincidence that Chrome has this problem too as they were
already doing the tabs in title bar stuff kind of.
I supsect that some mouse drivers expect that middle-click will be done on
certain types of child windows with certain window classname values. In
other words, there are probalby certain requirements that have to be
figured out.
It's just so strange that having certain other applications open causes it.
--
Michael
Mike Beltzner
> Yep, I have a bts account. I'll be glad to file on this later today. I already filed this for chromium <http://code.google.com/p/chromium/issues/detail?id=50135> to see what they think.
Thanks - please include that URL in the bug report, too, so we can share information with our friends in the Chromium project. Let us know what the bug number ends up being.
cheers,
mike
Michael A. Puls II
wrote:
> On 2010-07-28, at 12:20 AM, Michael A. Puls II wrote:
<https://bugzilla.mozilla.org/show_bug.cgi?id=582773>
It was either Core event handling or Firefox tab features for the
component. I chose the former.
--
Michael