Firefox's GPU Sandbox and X Mouse Button Control

[cmartin]

Hi there,

I'm one of the engineers that works on sandboxing for Mozilla Firefox. We recently enabled a sandbox for our GPU process on Firefox Nightly, and several users that use XMBC have reported that scrolling the mouse wheel stops working unless they click the check mark to disable the "Disable Scroll Window Under Cursor" feature.

I've done a bunch of investigating, and what we've determined is that the root cause of this issue is that XMBC installs a `WH_MOUSE_LL` hook and absorbs `WM_MOUSEWHEEL` messages, and then it uses an unknown algorithm to determine which window should receive the `WM_MOUSEWHEEL` message based on the location of the mouse pointer and other factors.

On our side of things, Firefox (and technically Chrome and Edge as well) has a separate process that we do all our rendering in (the so-called "GPU process") because graphics stacks are notoriously crash-y, and we don't want a graphics crash to take down the entire browser. So we create a "compositor window" in our GPU process and establish a parent-child relationship between it and the main browser window running in our main UI process. We mark this "GPU process compositor window" with `WM_DISABLED` to stop User32 from passing messages to us.

For reasons I haven't been able to figure out, XMBC sends `WM_MOUSEWHEEL` messages to our child "GPU process compositor window" instead of the main process UI window. This behavior is different from the normal User32 behavior, which sends the mouse message directly to the parent UI window (which I believe is correct, since the child window is disabled).

Thus far, this hasn't caused any issues, because our "GPU process compositor window" calls DefWindowProc(), which simply passes the WM_MOUSEWHEEL message up to its parent window in the main process -- So it's less than ideal, but it still basically worked.

Starting a few weeks ago, we enabled our GPU sandbox on Firefox Nightly. The GPU sandbox now means that the "GPU process compositor window" is running at Low Integrity Level. Since the main UI process is running at Medium Integrity Level, the compositor window is no longer able to pass the WM_MOUSEWHEEL message up to its parent using DefWindowProc().

When we found out what the root issue is, our first question was, "Why isn't this happening with Chrome?"... Chrome does the same thing we do: It has a low-integrity GPU process window that is a child of a medium-integrity main process window.

But when I investigated Chrome, I found out that -- for some reason -- XMBC actually *does* post the WM_MOUSEWHEEL message directly to Chrome's main UI window, and not the GPU process compositor window. But we have almost all of the exact same window characteristics: Our Window Class Style, Window Style, and Window Extended Style are all the same as Chrome's, and both of our WindowProc do nothing but make a call to DefWindowProc().

So, we were hoping we could ask you to help debug this issue? We don't have access to the source code for XMBC, but we were hoping you could help by downloading Firefox Nightly and trying to determine what it is that is causing XMBC to pick our GPU process compositor window instead of our main UI window for scrolling messages? And why does it not do the exact same thing for Chrome? Is there perhaps an application-specific override in XMBC for Chrome that Firefox should have as well?

(If it helps you debug, our compositor window should have a blank title and a window class of MozillaCompositorWindowClass, and our main window should have a real title and a window class of MozillaWindowClass)

For more info and background, we are tracking this issue on bugzilla-dot-mozilla-dot-org Bug number 1798014 (this forum doesn't allow external links)

If you would like to reach me privately to talk about this more, please feel free to contact me at cmartin-at-mozilla-dot-com or on chat-dot-mozilla-dot-org as "at-cmartin-colon-mozilla-dot-org"

[phil]

Hi Martin, thanks for getting in touch - this is a first for me - as in developers of other software getting in touch about XMBC interacting with their stuff. It makes a nice change

I'm a log time Firefox user, although to be honest, Waterfox tends to be my default of choice going back to the days before Firefox offered 64bit versions!) user but I tend not to delve into pre-release browsers too much.

Absolutely happy to try and figure out what is going on and adjust if required, but I do have a problem these days getting time to spend on XMBC which is an old hobby which unfortunately has lost out to the realities of life and work more often than not recently.

What it does, is intercept the WM_MOUSEWHEEL messages in the low level hook (as you correctly worked out) and redirects it to the window handle of the window under the cursor - UNLESS there is a predefined (hard coded) rule that it should not do this. The purpose being to scroll the window under the mouse, and not the active window. Obviously without knowing anything about how said window actually works - and this has certainly been more of a problem more recently (OK not that recent now I guess) with all the "out of process" sub windows!

I'm fairly certain that the reason Chrome behaves "OK" is because I have previously had to put in rules "workarounds" specifically for chrome and Edge which I never had to do for Firefox. XMBC looks at various things, mainly the window class, or the parent window class (etc) and perhaps the process name (I can't remember and its too late here to look right now) to determine if it is safe to redirect the scroll messages. So the rules from chrome will probably be subtly different but similar - thanks for letting me know the classes - so I may not even have to use Spy++ to find them

EDIT: Interesting that the window is disabled and YET XMBC still tries to redirect scroll messages to it - that sounds rather silly and I'm surprised it has never popped up/occurred to me before that that might be a bad idea! Its such an obvious thing to check!

Back in the days of Windows XP (64bit) when XMBC was first created as Microsoft's own tools did not support their shiny new 64bit version of XP, there was an 'old fashioned' power toy that did something similar to this and it was really useful, especially in many applications at the time that did not support scrolling properly with the wheel (VB6 anyone?!). But this feature is not really required these days since Windows 10 and 11 implement this natively and it should not be on by default as it currently is.

I'd suggest the best advise to anyone with this problem (in the short term at least) is to tick the "disable scroll window under cursor" box if on Windows 10/11 and let Windows handle it natively. This will probably be off by default in the next release anyway. But I will certainly try and find some time in the not too distant future to look into it and see if I can put the same or similar logic in place for Firefox if that works with the nightly build when I get a chance to give it a go.

Regards, and thanks for the detail
Phil

[cmartin]

Hi there,

Thank you very much for the help! Glad to hear that you're a Firefox fan, too I guess it's a bit disappointing that you've moved to Waterfox, but at-least you're still using a browser that is secure and respects your privacy -- Although maybe not quite as much as Firefox (I'm not biased at all )

At least now that we know that it's something that XMBC does specifically to fix Chrome and Edge, we are able to rule out a bunch of things.

It is a bit surprising that WM_DISABLE being ignored hasn't caused issues before, but who knows -- Maybe if you fix this, it will fix other mysterious issues that people have run into with XMBC? Sounds like a win-win situation to me!

FWIW I don't think that XMBC is the only program that has an issue like this -- One of the users that reported this issue (Gioxx) had said that they don't use XMBC, yet they had still run into it. So we will likely try to find a more general way to prevent this problem from happening with other tools that redirect mouse wheel events.

PS Good on you for making this software that's helped so many people. If I had known this thing existed back in the Windows XP days, I definitely would've used it. You did smart scrolling before it was cool!

Cheers!
Chris Martin

[phil]

Hi Chris,

I have had a play and indeed recreated the problem with the nightly firefox build. All fixed in XMBC 2.20 Beta - it will now a) respect the disabled window style and b) explicitly look for MozillaCompositorWindowClass and apply the same fix that it does for chrome.

So hopefully that will work - seems to be all OK here with the latest nightly build of Firefox.
It is available to test in XMBC 2.20 Beta 7 (available here)

Regards,
Phil

[xierch]

Hi there,

After upgrade to XMBC 2.20 Beta 7, the vertical mouse wheel works again while horizontal wheel seems still not working on my system with Firefox 109.0b3. Both vertical and horizontal mouse wheel work well on Chrome and Edge.

[phil]

OK I'll take a look - the vertical and horizontal is a different path so maybe I missed that!

[phil]

It should be fixed in 2.20 Beta 8 (just published so you should get notification of its availability soon, or just check for updates manually!)

[cmartin]

Hi Phil,

Just a friendly heads-up to let you know that the GPU Sandbox has "graduated" from Firefox Nightly, and will be enabled in the release of Firefox 110 on Feb 14, 2023. This means we can probably expect almost everyone that uses XMBC and Firefox together to run into this issue, not just people that are using our Nightly build.

We have created a knowledge base article ahead of time to explain the issue to our users, and we included instructions directing them to disable the XMBC "scroll under cursor" feature (or download your latest Beta).

That article is at support-dot-mozilla-dot-org/en-US/kb/x-mouse-button-control-firefox-110

Thanks again for the help, take care, and good luck!
Chris Martin

[phil]

Thanks Chris for the heads up!
Maybe I need to release 2.20 as it seems stable - I can push further changes to 2.21 beta! Actually I think my signing cert runs out soon so best do it before then in any case!