IsWindowVisible calls and win10 cloaked windows

854 views
Skip to first unread message

Joe Mason

unread,
Oct 5, 2020, 12:11:09 PM10/5/20
to jamie...@chromium.org, chromium-dev, s...@chromium.org, sad...@chromium.org, Nico Weber
Hi, ui/ OWNERS (and Jamie):

I just found this note on Raymond Chen's blog about a new window visibility mode in win10, "cloaked": https://devblogs.microsoft.com/oldnewthing/20200302-00/?p=103507

The obvious test is Is­Window­Visible(), which checks whether the window and all its parents have the WS_VISIBLE window style. If a window is not visible, then it doesn’t appear on the list.

But that will still find things like windows that belong to non-current virtual desktops, or bits of the shell that are currently not visible, or some UWP apps. What’s up with that?

The shell has a concept called cloaking, in which a window is given all the trappings of visibility, without actually being presented to the user. As far as the app can tell, it seems to be visible: It still has the WS_VISIBLE window style, its coordinates are still within the bounds of the monitor, it still gets WM_PAINT messages, it has a non-empty clipping region, all the ways a traditional Win32 app has of detecting whether it is on screen say, “Yup, you’re on screen. Everything is just fine!” 

It might be worth auditing calls to ::IsWindowVisible to see if they need to also check the "cloaked" state, which is detected with:

BOOL IsWindowCloaked(HWND hwnd)
{
 BOOL isCloaked = FALSE;
 return (SUCCEEDED(DwmGetWindowAttribute(hwnd, DWMWA_CLOAKED,
     &isCloaked, sizeof(isCloaked))) && isCloaked;
}
I did a quick scan for IsWindowVisible calls and found a bunch throughout ui/ that don't handle the new cloaked state, eg:



Also these two in remoting/host and webrtc, which are owned by Jamie:


There are also some calls in content/browser and chrome/browser, which is where I stopped looking.

WDYT?
Joe

Jamie Walch

unread,
Oct 5, 2020, 3:22:57 PM10/5/20
to Joe Mason, Joe Downing, chromium-dev, Scott Violet, sad...@chromium.org, Nico Weber

Comments in-line

The first of these is a window we've just created, so I don't think it needs to change (although I also don't think it would break anything if we wanted some centralized helper function to encapsulate this logic, and which did check for cloaked windows).

The second is more of a generic helper for the window capture code, and probably ought to handle cloaked windows. It's hard to tell exactly what's broken about the current behaviour though; do you know of any software that uses cloaked windows that we could test against? 

David Bienvenu

unread,
Oct 5, 2020, 3:41:08 PM10/5/20
to jamie...@chromium.org, Joe Mason, Joe Downing, chromium-dev, Scott Violet, sad...@chromium.org, Nico Weber
explorer.exe seems to create a cloaked window, which is normally way down in the z-order, but using RDP and resizing the desktop seems to bring it to the top. See https://bugs.chromium.org/p/chromium/issues/detail?id=939867#c14

- David

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CABhLwTUpAXyMca%2BPTMVtEb7-UTU0eAaZBTFgoVCo4ctCBmGrBQ%40mail.gmail.com.

Scott Violet

unread,
Oct 5, 2020, 7:41:09 PM10/5/20
to Joe Mason, jamie...@chromium.org, chromium-dev, Sadrul Chowdhury, Nico Weber
On Mon, Oct 5, 2020 at 9:07 AM Joe Mason <joenot...@google.com> wrote:
Hi, ui/ OWNERS (and Jamie):

I just found this note on Raymond Chen's blog about a new window visibility mode in win10, "cloaked": https://devblogs.microsoft.com/oldnewthing/20200302-00/?p=103507

The obvious test is Is­Window­Visible(), which checks whether the window and all its parents have the WS_VISIBLE window style. If a window is not visible, then it doesn’t appear on the list.

But that will still find things like windows that belong to non-current virtual desktops, or bits of the shell that are currently not visible, or some UWP apps. What’s up with that?

The shell has a concept called cloaking, in which a window is given all the trappings of visibility, without actually being presented to the user. As far as the app can tell, it seems to be visible: It still has the WS_VISIBLE window style, its coordinates are still within the bounds of the monitor, it still gets WM_PAINT messages, it has a non-empty clipping region, all the ways a traditional Win32 app has of detecting whether it is on screen say, “Yup, you’re on screen. Everything is just fine!” 

It might be worth auditing calls to ::IsWindowVisible to see if they need to also check the "cloaked" state, which is detected with:

BOOL IsWindowCloaked(HWND hwnd)
{
 BOOL isCloaked = FALSE;
 return (SUCCEEDED(DwmGetWindowAttribute(hwnd, DWMWA_CLOAKED,
     &isCloaked, sizeof(isCloaked))) && isCloaked;
}
I did a quick scan for IsWindowVisible calls and found a bunch throughout ui/ that don't handle the new cloaked state, eg:


I don't believe this is used in production, so no urgency here. That said, a TODO should be added in case we did try to use this code.
This is used to determine where dragged tabs should be attached. This should likely be updated.
I think this should be updated, but I think we'll need to ensure that it doesn't consider our own windows.

  -Scott
Reply all
Reply to author
Forward
0 new messages