Able to reproduce on 60.0.3112.113 and latest canary 63.0.3205.0 with the mentioned steps in comment#0 on Ubuntu 14.04,Mac 10.12.6 and windows 7
This seems to be a Non-Regression issue seen from M-50[50.0.2624.0] as well.

This issue is reproducible on Firefox too. Marking this as Untriaged for further investigation and inputs on the correct behaviour from the respective team.

I can't reproduce it on my Win10 laptop https://appear.in. The remote user will see only the shared window while the other side is hovering/highlighting other opened windows on taskbar.
Also I can't reproduce it with local desktopCapture samples.

In the attached recording, there seems no remote user joined. So what's on the screen at remote side? Could you please take some screen shots?

What replication step I might miss here?

This is a really serious issue, agreed. 

It seems like this issue might actually be to do with the way that some programs on Windows 8.1/10 use hardware graphics acceleration, and the way that WebRTC is capturing the media. (I can't take credit for figuring this out, the team at Temasys pointed me in the right direction.) 

The steps to reproduce that the first user reported are correct, but when sharing an application you have to choose an application that takes advantage of the default hardware graphics acceleration on these versions of Windows, for example pretty much any Microsoft application, including default Windows system applications such as the File Explorer. Most notably though is the whole Microsoft Office suite. 

This means that anyone using WebRTC in a business context who is sharing a PowerPoint (which is the norm for any business user who does screen sharing), if they hover over an icon on the taskbar of another application (that they aren't sharing) and then hover over it's thumbnail preview, the viewer will instantly see the other (non-shared application). Here are the specific steps to reproduce...

STR:
1) Open Google Hangouts in Chrome on a Windows 10 machine (this is the PRESENTER)
2) Open the same Hangout in Chrome on another machine (doesn't matter what OS) (this is the VIEWER)
3) PRESENTER clicks Share screen in Hangouts
4) PRESENTER opens a PowerPoint file 
5) PRESENTER chooses application from Chrome selection dialog box
6) PRESENTER chooses to share the PowerPoint application
7) VIEWER sees the PowerPoint application that is being shared
8) PRESENTER hovers over the Chrome icon in the Windows taskbar and then hovers over the thumbnail image of the Chrome window, but does NOT click on the Chrome window
9) VIEWER can see the Chrome window even though the PRESENTER selected that ONLY the PowerPoint application should be shared

I have reproduced this over and over again on Windows 10 (Chrome: Version 61.0.3163.100 (Official Build) (64-bit)), and it can be reproduced on Windows 8.1, but I've never reproduced it on Windows 7 or Mac machines. Note that the presenter HAS to select sharing an application and choose a Windows default app or Microsoft app (IE, Office, etc.) in order to have this happen. If the presenter selects sharing an application but chooses something like Chrome, it won't trigger this bug. Presumably this is because Chrome doesn't take advantage of the Windows built in hardware graphics accelerator the way that Microsoft (and Windows) does. Note also that, as the first reporter mentioned, this bug is to do with any sharing screen via Chrome WebRTC, not limited to Google Hangouts. It's also worth mentioning that the Hangouts preview of what you're sharing shows the same as what the viewer sees - so it seems to again indicate it's a problem with the way it's capturing the media. It actually doesn't matter at all if you have a second person on to view, but it's a lot easier to see the issue that way.

Ultimately though, consider the situation of a business user (or any user). They are choosing to share only their PowerPoint because they don't want others to see their chat window, etc. Then someone sends them a confidential message via Slack or other IM, and being the good multi-tasker that they are, they just hover over the thumbnail of the Slack application to quickly read the message. Their expectation is that since they have chosen to share only the application, that no one viewing will be able to view the Slack message they are reading. But because of this bug, the viewer(s) can see their Slack messages.

Sorry, this is a long message but hopefully it gives what you need to be able to reproduce it and escalate it appropriately. I'm happy to answer any questions if any of the above is unclear.

Incidentally, I found this separate bug that discusses the hardware graphics acceleration: https://bugs.chromium.org/p/chromium/issues/detail?id=741770 and the way it should stop sharing (essentially freeze the image) if the shared application is covered.

I suppose that Chrome isn't detecting that the app being shared is covered, since I imagine that hovering over another app thumbnail is technically not covering it in the same way as if you drag an application over the top of the shared app, but the problem detailed above remains a major concern. Is there a fix for this?

I believe #c7 is the root cause. I will have a look if we can detect the hover-thumbnail on Windows.
Also I believe Chrome should also be impacted by this issue. If not, something in CroppingWindowCapturerWin::ShouldUseScreenCapturer() is wrong.

As mentioned in #c7, we have to use "cropping" capturer, because the regular window capturer cannot capture applications using HW acceleration.

I can reproduce the issue on my machine.

Glad to know that you can reproduce it...Any luck with being able to detect the hover-thumbnail on Windows 8.1/10?

Unfortunately I have not looked into it yet.

Have you looked into whether you can detect the hover-thumbnail?

The way I found to detect "Aero Peek" mode is not easy to be integrated to the capturer. It needs a Windows message loop, which is not what we expected in the capturer concept. Also, using a magic string "Task Switcher" is not recommended.
https://stackoverflow.com/questions/5385735/how-to-detect-if-aero-peek-mode-is-on

Another choice is to disable "Aero Peek" when window capturer is working.
http://troubleshooter.xyz/wiki/enable-or-disable-thumbnail-previews-in-windows-10/

It seems that Microsoft itself has such problem too. This problem can be reproduced by Skype window sharing.

Seems no easy way to handle it by programming...?

as reported in  issue783971 , same problem happens to start window UI too.

Deleted: share-out-start-window.png 437 KB

	share-out-start-window.png 437 KB View Download