Screen Sharing: Source Selection Dialog Does Not Appear (macOS).
Reported by
tylercof...@gmail.com,
Jan 24 2018
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.119 Safari/537.36 Steps to reproduce the problem: I will explain it with text as best I can, but really you should just watch this video. https://logmeininc-my.sharepoint.com/:v:/g/personal/tyler_coffman_logmein_com/Ec5M7hH9_I5KvL7zKzotX9gBMilum2LNNNcY4luQbsVcxw?e=Ke5bbb We offer a free tier of GoToMeeting which should be sufficient to reproduce this bug without having to spend any money. Equipment requirements: - A mac computer with 2 screens (such as a laptop + 1 external monitor). - Another computer or mobile device that can host a GoToMeeting session. Instructions to be done on the other machine will be prefixed with (Other) and instructions to be done on the mac will be prefixed with (Mac). 1. (Other) Start a GoToMeeting session on a different device than the macOS machine where the bug will occur. 2. (Mac) Join the meeing with the in-browser version of GoToMeeting. 3. (Mac) Have the chrome window with GoToMeeting on one monitor, and then have another chrome window on the other monitor. 4. (Mac) Click the chrome window that is on a different monitor than the GoToMeeting chrome window, so that the chrome window on the other monitor has focus. Make sure that this other window has focus when performing this next step. 5. (Other) Make the Mac user the presenter. 6. (Mac) Observe that the dialog box to choose the screen sharing source does not appear. 7. (Mac) Move the chrome window that has the GoToMeeting tab around until the dialog shows up on the other monitor, which will likely look transparent for some odd reason until the dialog is clicked. We have figured out how to workaround this bug in our Chrome extension, by giving the window containing the GoToMeeting tab focus before displaying the dialog, so you may not be able to reproduce this using our GoToMeeting Pro Screen Sharing Extension if we have shipped an updated extension before you try to reproduce this. If that is the case, roll back to an older version of the extension. This is the extension we use for screen sharing: https://chrome.google.com/webstore/detail/gotomeeting-pro-screensha/gcgikpombjkodabhbdalkcdhmllafipp To reproduce this issue, use GoToMeeting Pro Screensharing Version 1.0.0.0 (Updated July 21, 2017). This line added to the extension lets us work-around the bug, but the bug should still be fixed in Chrome: ``` chrome.windows.update(tab.windowId, {focused: true}); ``` What is the expected behavior? When the other GoToMeeting user makes you the presenter, the dialog box should appear and you should be able to use it to show a screen sharing source. What went wrong? The screen sharing dialog box does not appear, and only appears if you click and drag the window containing the GoToMeeting tab, at which point the dialog shows up on the other monitor and is weirdly transparent in parts and opaque in others until clicked, at which point it renders correctly. Did this work before? No Chrome version: 64.0.3282.119 Channel: stable OS Version: OS X 10.12.6 Flash Version: Email me at tyler.coffman@logmein.com if you have any questions.
,
Jan 25 2018
Able to reproduce the issue on reported chrome version 64.0.3282.119 and on the latest canary 66.0.3330.0 using a dual monitor setup with Windows 10 laptop(HP elite book) and hp monitor. As the issue is seen from M60(60.0.3072.0) considering it as non-regression and marking it as untriaged. Note: Unable to check the issue on Mac OS, as ET team doesn't have setup for dual monitor set up on Mac OS. Hence requesting Inhouse team to confirm the same on Mac OS. Romoving Needs-Bisect label and adding TE-NeedsTriageFromHYD for confirmation of Mac OS behavior. Attaching the screen cast from M60 for reference. Thanks!
,
Jan 25 2018
Vamshi, your video does not show that you have reproduced the bug. I see no instance of the Web version of GoToMeeting running, only the native client. Without seeing the screen of the machine that the 'Chrome Testing' client, it can't be confirmed that you have reproduced the bug. Also, your video fails to demonstrate that this bug occurs on windows, because you aren't even running the Chrome version of G2M on windows. The fact that the 'Verify Presenter Change' dialog shows up on your other monitor when you make the other user the presenter has nothing to do with this chrome bug, because that dialog belongs to the pure-native GoToMeeting process that you are running. It appears to me that this issue being marked as affecting Windows as well as Mac is in-error, and the issue should be once again marked as only affecting Mac.
,
Jan 25 2018
Mac triage: marking for GetUserMedia triage.
,
Jan 26 2018
Tyler, can you please check whether chooseDesktopMedia gets called from your extension or not when the picker doesn't appear? We need to find out if this issue is about screensharing or webpage -> extension communication.
,
Jan 26 2018
I can check and find out for sure, but here are the reasons why I am pretty confident that our extension is properly calling chooseDesktopMedia: - The window only doesn't show up when another chrome window on another screen has focus. - The bug can't be reproduced on Windows, but the extension code should be platform independent. - Moving the Chrome window that has the GoToMeeting tab makes the dialog suddenly appear, but with significant visual artifacts such as parts of the dialog being transparent. Moving the mouse over this dialog without clicking it makes the visual artifacts worse. Our extension has no logic that would cause it to call chooseDesktopMedia based on the window being moved.
,
Jan 30 2018
Re #7, I'm not saying that there a bug in the extension, but there could be something broken in the web page -> extension message passing for this specific case. So please confirm that the extension gets invoked and calls chooseDesktopMedia.
,
Jan 30 2018
Niklase, I have used the extension developer tools to confirm 100% that yes, in the specific case that causes this bug to occur, the extension is being invoked and the extension is calling chrome.desktopCapture.chooseDesktopMedia. If you set the breakpoint on the call to chrome.desktopCapture.chooseDesktopMedia, you must make sure that the Developer Tools window that you are using to debug the extension is on the other monitor. This is because the breakpoint triggering causes the developer tools window to steal focus. The bug only occurs if a chrome window on the other monitor has focus when the call to chooseDesktopMedia occurs, so the developer tools window must be on the other monitor when you resume execution.
,
Mar 19 2018
Mac triage: marking assigned to niklase@ and stripping needs-feedback.
,
May 25 2018
Assuming this should be bumped to M69? |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by manoranj...@chromium.org
, Jan 25 2018