685225 - "Close" keyboard/mouse button closes whole browser when it should close open tab

Status: NEW

(Firefox :: General, defect)

Description

[[:Cww]]

Intellipoint mice and some other drivers (Microsoft keyboards etc) sometimes have a "close" button which in other programs closes the active tab but in Firefox closes the whole browser.

See

https://support.mozilla.com/en-US/questions/810972

Comment 1

[Steven Michaud [:smichaud] (Retired)]

> https://support.mozilla.com/en-US/questions/810972

Sounds like this problem is cross-platform, and not specific to the Mac.  Is that true?

Comment 2

[[:Cww]]

One mouse model mentioned is: Microsoft Wireless Mouse 6000 but that doesn't seem to much matter, it's the Microsoft Intellipoint mouse settings for windows. (May be Windows 7 specific).

Comment 3

[[:Cww]]

(In reply to Steven Michaud from comment #1)

I forgot to change that when I filed the bug, it's windows (or maybe just windows 7)

Comment 4

[Benjamin Smedberg]

I understand that this is a regression? If so, can we get a regression range? Does anyone know exactly what mechanism these buttons use to close something?

Comment 5

[[:Cww]]

Ugh, missed this comment.  This seems to have happened in Firefox 6.

We're asking users to do the following:

Change Intellipoint settings / Program Specific Settings / Firefox / Keystroke (Ctrl + W)

Comment 6

[Paul Gregg]

Can confirm this is wider than just Windows 7. Happens on Vista (32bit Home Premium) fully updated with the latest IntelliPoint v8.2 installed. Works correctly in IE9 but not FF12.

Can anyone point out how to capture the event that the drivers send FF so we can fix this regression?

Comment 7

[Timothy Nikkel (:tnikkel)]

You could try using Winspector, but I'm not sure if that will yield helpful results or not.

Comment 8

[Paul Gregg]

Ok, here's what I've discovered so far:
Couldn't get Winspector to work (just hour-glassed Vista for minutes at a time), but the open source 'Window Detective' works well.
On a simple MDI application, IntelliPoint sends WM_KEYDOWN [VK_CONTROL] followed by WM_KEYDOWN [VK_F4]. This works in Firefox if you use this keyboard combination, but unfortunately IntelliPoint doesn't send this to Firefox.

IntelliPoint sends this to Firefox (all are Async except for WM_CLOSE):
WM_APPCOMMAND (0x319)
WM_SYSKEYDOWN (0x104) virtual key = VK_MENU
WM_SYSKEYDOWN (0x104) virtual key = VK_F4
WM_SYSKEYUP   (0x105) virtual key = VK_F4
WM_KEYUP      (0x104) virtual key = VK_MENU
WM_SYSCOMMAND (0x112)
WM_CLOSE      (0x10)


I checked in IE9 but it's hard to work out what is going on, selecting the window of the page doesn't seem to indicate anything. If the outer window is monitored, it receives a sync WM_APPCOMMAND message which it then returns 0.
Based on http://msdn.microsoft.com/en-us/library/windows/desktop/ms646275%28v=vs.85%29.aspx & the patches in Bug 30431, you need to return TRUE to tell Windows you have handled the message. But I haven't been able to work out what parameters WM_APPCOMMAND contain while monitoring with Window Detective.


Looking at the MSDN page, the fix may be to just add APPCOMMAND_CLOSE case's to /widget/windows/nsWindow.cpp DispatchCommandEvent() & ProcessMessage() functions.
 -> Looks like the code has changed a lot since Bug 30431 was checked in, nsEventStateManager.cpp doesn't contain any APPCOMMAND stuff at all now.
Unsure how the IntelliPoint driver decides what messages to send to which applications. Maybe something needs to be set or configured somewhere, hopefully not.

Comment 9

[Danielle Muradina]

Attachment: techmoravind19734937.txt

Thanks from cibeschsodut1975.