Alright -- I have a bunch more information about this bug, including a mostly-complete explanation of the root cause:
# Root cause
- We have a "compositor window" that runs in the GPU process that is a child window of the tab widget in the
main UI process. It has the WS_DISABLED window style, so it should be ignored by Win32 for the purposes
of message processing.
- XMBC offers a feature that emulates the Windows 10 behavior of sending mouse wheel events to whatever window is
currently under the mouse cursor, even if that window isn't the current focus window.
- To accomplish this, XMBC installs low-level mouse hook, which swallows scroll messages instead of passing them
through to Win32. It uses its own logic to figure out what the target window should be.
- It incorrectly identifies the GPU process "compositor" window as the target of the scroll message and posts it
to its message queue, even though the window is marked as disabled.
- However, even though this is technically a bug, it actually works under normal circumstances because the
DefWindowProc just bubbles the message up to the parent window of the process.
- But once we enable the GPU Sandbox, we lower the integrity level of the compositor window.
- When it tries to re-post the scroll message to its parent window, it can't because a low-integrity process
can't post messages to a medium-integrity window.
# Other stuff we know
- Scrolling works if the (initial, delayed) integrity levels are (medium, low), but (low, low) is broken.
- Bob Owen mentioned that he's seen this type of thing before. Apparently there are some User32 subsystem
things that get initialized in early process startup at "medium" integrity, so after the drop they are still
able to post messages to higher-integrity windows.
- Without XMBC, Windows respects the WM_DISABLED flag and just posts all scroll messages directly to the
parent window.
- XMBC is not the only software that has this issue, since Gioxx has said that he doesn't use XMBC and still
experienced it.
# Potential Solutions
- Use "initial=medium, delayed=low" for the integrity level.
- The main issue is that this means the GPU process can spam input events at the main process, possibly other
UI actions are allowed. Likely weakens the GPU sandbox a lot.
- Re-post scroll wheel events to the main process using IPDL.
- Might be easy, or might be absurdly difficult... Win32's behavior is often very complex and has a variety of
weird edge cases when it comes to bubbling up input events and coalescing events together. I could imagine a
long tail of weird behaviors requiring constant adjustments.
- Simply detect that the wrong thing is happening and inform the user somehow.
- We should never see input messages being posted to the queue of the GPU process compositor window, so if we
do see them, that tells us that some program is doing the wrong thing.
- Perhaps we can do something like display a message window with a link to SUMO or something?
- Maybe there is some way to ensure that the GPU compositor window is even less likely to be chosen by tools like
XMBC
- I'm going to contact the author of the software to ask how XMBC makes this decision
- Perhaps there are other flags that can be set on a window to make it "super-disabled"
- Investigate other ways to have GPU process render to UI window that don't involve this GPU-process-child to
UI-process-parent thing?
Bug 1798014 Comment 64 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Alright -- I have a bunch more information about this bug, including a mostly-complete explanation of the root cause:
# Root cause
- We have a "compositor window" that runs in the GPU process that is a child window of the tab widget in the
main UI process. It has the WS_DISABLED window style, so it should be ignored by Win32 for the purposes
of message processing.
- XMBC offers a feature that emulates the Windows 10 behavior of sending mouse wheel events to whatever window is
currently under the mouse cursor, even if that window isn't the current focus window.
- To accomplish this, XMBC installs low-level mouse hook, which swallows scroll messages instead of passing them
through to Win32. It uses its own logic to figure out what the target window should be.
- It incorrectly identifies the GPU process "compositor" window as the target of the scroll message and posts it
to its message queue, even though the window is marked as disabled.
- However, even though this is technically a bug, it actually works under normal circumstances because the
DefWindowProc just bubbles the message up to the parent window of the process.
- But once we enable the GPU Sandbox, we lower the integrity level of the compositor window.
- When it tries to re-post the scroll message to its parent window, it can't because a low-integrity process
can't post messages to a medium-integrity window.
# Other stuff we know
- Scrolling works if the (initial, delayed) integrity levels are (medium, low), but (low, low) is broken.
- Bob Owen mentioned that he's seen this type of thing before. Apparently there are some User32 subsystem
things that get initialized in early process startup at "medium" integrity, so after the drop they are still
able to post messages to higher-integrity windows.
- Without XMBC, Windows respects the WM_DISABLED flag and just posts all scroll messages directly to the
parent window.
- XMBC is not the only software that has this issue, since Gioxx has said that he doesn't use XMBC and still
experienced it.
# Potential Solutions
- Use "initial=medium, delayed=low" for the integrity level.
- The main issue is that this means the GPU process can spam input events at the main process, possibly other
UI actions are allowed. Likely weakens the GPU sandbox a lot.
- Re-post scroll wheel events to the main process using IPDL.
- Might be easy, or might be absurdly difficult... Win32's behavior is often very complex and has a variety of
weird edge cases when it comes to bubbling up input events and coalescing events together. I could imagine a
long tail of weird behaviors requiring constant adjustments.
- Simply detect that the wrong thing is happening and inform the user somehow.
- We should never see input messages being posted to the queue of the GPU process compositor window, so if we
do see them, that tells us that some program is doing the wrong thing.
- Maybe we add the fact that it occurred to `about:support`?
- Perhaps we can do something like display a message window with a link to SUMO or something?
- Maybe there is some way to ensure that the GPU compositor window is even less likely to be chosen by tools like
XMBC
- I'm going to contact the author of the software to ask how XMBC makes this decision
- Perhaps there are other flags that can be set on a window to make it "super-disabled"
- Investigate other ways to have GPU process render to UI window that don't involve this GPU-process-child to
UI-process-parent thing?
Alright -- I have a bunch more information about this bug, including a mostly-complete explanation of the root cause:
# Root cause
- We have a "compositor window" that runs in the GPU process that is a child window of the tab widget in the
main UI process. It has the WS_DISABLED window style, so it should be ignored by Win32 for the purposes
of message processing.
- XMBC offers a feature that emulates the Windows 10 behavior of sending mouse wheel events to whatever window is
currently under the mouse cursor, even if that window isn't the current focus window.
- To accomplish this, XMBC installs low-level mouse hook, which swallows scroll messages instead of passing them
through to Win32. It uses its own logic to figure out what the target window should be.
- It incorrectly identifies the GPU process "compositor" window as the target of the scroll message and posts it
to its message queue, even though the window is marked as disabled.
- However, even though this is technically a bug, it actually works under normal circumstances because the
DefWindowProc just bubbles the message up to the parent window of the process.
- But once we enable the GPU Sandbox, we lower the integrity level of the compositor window.
- When it tries to re-post the scroll message to its parent window, it can't because a low-integrity process
can't post messages to a medium-integrity window.
# Other stuff we know
- Scrolling works if the (initial, delayed) integrity levels are (medium, low), but (low, low) is broken.
- Bob Owen mentioned that he's seen this type of thing before. Apparently there are some User32 subsystem
things that get initialized in early process startup at "medium" integrity, so after the drop they are still
able to post messages to higher-integrity windows.
- Without XMBC, Windows respects the WM_DISABLED flag and just posts all scroll messages directly to the
parent window.
- XMBC is not the only software that has this issue, since Gioxx has said that he doesn't use XMBC and still
experienced it.
# Potential Solutions
- Use "initial=medium, delayed=low" for the integrity level.
- The main issue is that this means the GPU process can spam input events at the main process, possibly other
UI actions are allowed. Likely weakens the GPU sandbox a lot.
- Re-post scroll wheel events to the main process using IPDL.
- Might be easy, or might be absurdly difficult... Win32's behavior is often very complex and has a variety of
weird edge cases when it comes to bubbling up input events and coalescing events together. I could imagine a
long tail of weird behaviors requiring constant adjustments.
- Simply detect that the wrong thing is happening and inform the user and/or support engineers somehow.
- We should never see input messages being posted to the queue of the GPU process compositor window, so if we
do see them, that tells us that some program is doing the wrong thing.
- Maybe we add the fact that it occurred to `about:support`?
- Perhaps we can do something like display a message window with a link to SUMO or something?
- Maybe there is some way to ensure that the GPU compositor window is even less likely to be chosen by tools like
XMBC
- I'm going to contact the author of the software to ask how XMBC makes this decision
- Perhaps there are other flags that can be set on a window to make it "super-disabled"
- Investigate other ways to have GPU process render to UI window that don't involve this GPU-process-child to
UI-process-parent thing?