Unable to reproduce the issue on Windows 10,Mac 10.11.4,Linux Ubuntu-14.04 with Chrome stable version and latest Canary-56.0.2891.0-observed selected window persists above other windows.

Please find the attached screencast & let us know if we miss anything to reproduce the issue.  

Thanks.

Deleted: 656420-Mac.mov 4.7 MB

656420-Mac.mov 4.7 MB Download

My friend updated to latest stable 54 (he was on 53). Will have him test and I'll get back to you.

Hey guys it seems like this may be fixed for my friend after he upgraded to 54 from 53. Noticed there were updates to the picker as well, so perhaps something got fixed. :-P Either way just thought I'd let y'all know!

Then let me close this issue.

Hey Qiang,

Unfortunately my same roommate was able to reproduce this again just now. I suppose it's not solved. :-\

Vinay

tested on mac
1. the Picker window can be hidden by the main window
2. By design, we set the window as modal to the main window, and thus impossible to be hidden.

tested on Linux:
1. the picker window is standalone and can be hidden by the main window.
2. By design, we prefer using an in-window widget to represent the picker dialog, in which case, no such conception as hidden by main window. We only  fallback to use standalone window to represent the picker, if parent window is not specified.

This shows under this circumstance, the parent window is not properly specified. 

Actually I can think of three possible cases that chooseDesktopMedia is called.

1. A standalone chrome app, which has its own UI.
2. Like hangouts, the JS command is initiated from the website javascript.
3. Like your extension, it interacts with some website, but the JS command is not from the website.

I think we've handled the first two cases properly, but not the third. 
In the third case, it looks like that the JS stack space for the extension code is different from the JS stack space for the website, and thus failure to identify parent window somehow.

I will take a deeper look.

Thanks Qiang! That seems like a good logic tree to explore. Something I actually just thought of is that our loading popup comes up every time the modal hides. If the extension popup window opens when the desktop picker is open, would that potentially hide the picker behind that window?

Attached a video to show you.

Deleted: desktop-chooser-hides.mp4 1.3 MB

	desktop-chooser-hides.mp4 1.3 MB View Download

My guess is that loading popup forces the focus back to the browser, then the picker will be hidden (because it is not modal, as I explained previously)

#10: ok so I think I get what's going on then:

1. keyboard shortcut to activate extension
2. background script logic runs, asking for desktop recording
3. popup drops down

Should it be that 2 and 3 are flipped? Not sure how to make sure that 2 and 3 flip from my end besides a setTimeout or something like that.

I am looking for a way trying to make the picker modal. 

But it seems not that easy, as we do not naturally have the parent window pointer. (The parent window of the background JS is null)

#13: Making the picker a modal would be ideal. That's how I would expect it to behave.

Any way to pass the parent pointer through some context from the browser action fire (either keyboard shortcut or clicking the extension icon)? Perhaps that's a bit too nested of a logic path.

Also do modals behave in a way where they only sit on top of one window frame, or should they persist on top of all windows? Wondering why they require a parent window pointer to be created.

I don't know the code base - just shooting out ideas. :-P

By the limitation of OS, we can only set a window to be modal to another window. 

In the code path we just set the picker to be modal to the window containing the tab initiating the javascript call. 
However, for your case, the background javascript is kind of "orphan", which does not belong to any tab, and thus such parent window does not exist.

Another way is to fall back to set picker to be modal to the window containing the current active tab, in the case of background javascript, instead of being not modal. 

But I'm not sure whether that's proper behavior. So far I cannot think of a counterexample. I'll write a CL, and see what code reviewers would say.

Hmm yeah same boat. That seems correct, but maybe someone else will remember an edge case where that produces bad behavior. Keep me posted!

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4af22d6bdd6712738296923c5d04da4976f555c3

commit 4af22d6bdd6712738296923c5d04da4976f555c3
Author: qiangchen <qiangchen@chromium.org>
Date: Wed Oct 26 21:18:41 2016

Bug Fix: Desktop Capture Picker Not Modal

When the chooseDesktopMedia is initiated from a background Javascript, the picker is not modal, and thus there is a chance the picker is totally covered by the main window, and hard for the user to find it out.

This CL forces the parent of the picker window to be the most recent active browser window in case of a background Javascript. Then the picker will be modal.

BUG= 656420 

Review-Url: https://codereview.chromium.org/2428383008
Cr-Commit-Position: refs/heads/master@{#427797}

[modify] https://crrev.com/4af22d6bdd6712738296923c5d04da4976f555c3/chrome/browser/extensions/api/desktop_capture/desktop_capture_base.cc

Tested the issue on Mac 10.11.6 using chrome dev version #56.0.2902.0 as per the comment #0

Observed that the same behaviour in reported(53.0.2785.143) and the fixed(56.0.2902.0) version .

Please confirm the verification steps and expected behaviour,if I missed any steps to reproduce the issue.
Please find the attached screencast for reference.
Thanks...!!

Deleted: 656420.mov 9.3 MB

656420.mov 9.3 MB Download

In above video, I do not think you'd ever tested the issue.

Here are the steps:
1. Install Openvid Screen Recorder extension from google store
2. Run the recorder
3. When the screen source picker window opens, click the browser window to verify that the browser window cannot hide the picker window.

#20: yep that seems like the proper order of ops.

Tested the issue on Mac-10.11.6 using chrome version 56.0.2902.0 with steps from comment-20.
Observed that the browser window cannot hide the picker window.

Please find the attached screencast for reference.

Adding TE-Verified labels.

Thanks.

Deleted: issue-656420.mov 4.8 MB

issue-656420.mov 4.8 MB Download

:-) :-) :-) :-)

[bulk-edit : please ignore if not applicable]

Could you please set the correct milestone for this issue?

Verified in Chrome M56 in Mac 10.11.6 with repro steps from comment #20 - the browser window does not hide the picker window