Issue metadata
Sign in to add a comment
|
Window and screen sharing malfunction if primary and secondary monitors are swapped
Reported by
jan.eg...@gmail.com,
Apr 26 2017
|
|||||||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.81 Safari/537.36 Steps to reproduce the problem: 1. On any screen-capturing site (hangouts, our own) or even using the Desktop Capture Sample app, share a window that sits on what Chrome calls "Screen 2". 2. Move the shared window so it is partly on Screen 2 and partly on Screen 1, i.e. straddles the border between the screens. What is the expected behavior? Window continues to be shared normally What went wrong? Chrome crashes completely, all Chrome windows and instances vanish Crashed report ID: see attached, from 60.0.3081.0 How much crashed? Whole browser Is it a problem with a plugin? No Did this work before? Yes 57.0.2987.133 (64-bit) Chrome version: 58.0.3029.81 Channel: beta OS Version: 10.0 Flash Version: This issue resembles https://bugs.chromium.org/p/chromium/issues/detail?id=712615 but is not the same. Colleagues have verified that 712615 is actually fixed in Canary while I can still reproduce this issue with 60.0.3081.0 (Official Build) canary (64-bit). Probably pertinent: what Chrome calls "Screen 1" is my main display and "Display 2" according to Windows - Chrome's "Screen 2" is Windows' "Display 1". The layout is that "Display 1" is to the left of "Display 2" - if I switch the two, so that "Display 1" is to the right of "Display 2", I cannot reproduce the issue anymore. More effects: if I try to share a window on "Screen 2" (and don't move it...), what's actually grabbed is the area covered by the window *but on Screen 1*. If I try to share the whole "Screen 2", sharing fails (with Canary, 58 crashes in that case as well). If you need more details (or clearer explanations) please let me know. Thanks!
,
Apr 27 2017
Tested in chrome # 57.0.2987.133 and Stable #58.0.3029.81 and Canary #60.0.3081.0 on win 10.0 and not able to reproduce the issue. 1.Login to Hangouts and share the the screen 1. 2.Move the shared window to screen 2. Able to move the shared window to screen 2 without any crashes. @Reporter:Could you please let me know if i have missed anything and if possible,Please create new profile without extensions and apps.Re-check once in latest Stable #58.0.3029.81 and Canary #60.0.3081.0 and let us know the observations of the issue which would help us to triage the issue further. @ zijiehe : Could you please check once.This issue similar to https://bugs.chromium.org/p/chromium/issues/detail?id=712615. Thanks in Advance.
,
Apr 27 2017
I believe a vital point is the layout of the displays, i.e. that "Screen 2" is left of "Screen 1". I have put a couple of screenshots that hopefully add some clarity here: https://docs.google.com/document/d/1pC6KHfrcRM87r9gQE15dtVBJLCIeBr-R8RETI2tmO4E/edit?usp=sharing This test has been done with a freshly installed Canary #60.0.3082.0, w/o any extensions. Dump file attached (auto-upload doesn't work here, probably for infrastructure reasons) Will try out 58 stable next.
,
Apr 27 2017
Thank you for providing more feedback. Adding requester "rbasuvula@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 27 2017
rbasuvula@ - absolutely the same behavior on #58.0.3029.81, with fresh profile and no extensions.
,
Apr 27 2017
Just to confirm whether its same as Issue 715756 , would you mind providing us with crash id?
,
Apr 27 2017
Will do tomorrow when back in office. Question though, as indivated above auto-upload of crash dumps doesn't work at my office. Therefore I attached the dumps from local machine. Is the ID still relevant fir you in this case? Sorry if this is a stupid question you've answered already a hundred times...
,
Apr 27 2017
Thanks for the immediate response. I analysed the mini dump, but did not find any valuable information to draw a conclusion.Please provide us with crash id from chrome://crash when time permits.
,
Apr 27 2017
I have got a reproduce on my machine. The DirectX capturer works malfunctionally if the primary monitor is on the right, but secondary is on the left.
,
Apr 27 2017
I would suggest we disable DirectX capturer in M58. I am working on a fix, and hopefully it can catch M59.
,
Apr 27 2017
To be more clear, I mean the blank screen instead of crashing.
,
Apr 27 2017
So this bug looks different from issue : 712615 zijiehe@ please confirm. As per #9 updating the labels.
,
Apr 27 2017
Confirmed, no, they are different. But the title should be updated to: Window and screen sharing malfunction if primary and secondary monitors are swapped.
,
Apr 27 2017
Instead of a code change, I would suggest to use experiment flag to disable this feature. (https://cs.chromium.org/chromium/src/content/browser/media/capture/desktop_capture_device.cc?rcl=d9b2071593f2049982dde69ade697170e85cdb96&l=67)
,
Apr 27 2017
Confirmed, this is a code defect in DirectX capturer components. Change https://codereview.chromium.org/2848443004/ can fix this issue.
,
Apr 28 2017
Re #8 - here you go: Crash ID a0e58f67-5d29-45b7-82e5-8265094be663 Crash report captured on Thursday, April 27, 2017 at 1:03:45 PM (upload requested by user, not yet uploaded)
,
Apr 28 2017
The following revision refers to this bug: https://chromium.googlesource.com/external/webrtc.git/+/049ec71e657eef3d15e0f15d60acb1a71e81b521 commit 049ec71e657eef3d15e0f15d60acb1a71e81b521 Author: zijiehe <zijiehe@chromium.org> Date: Fri Apr 28 20:43:28 2017 Allow Windows to return a monitor out of the first quadrant Windows may return a DesktopCoordinate out of the first quadrant (x >= 0 && y >= 0), this typically happens when the primary and secondary monitors are swapped. i.e. The secondary monitor is on the left but the primary one is on the right. This change "moves" the entire screen from any quadrant to the (0, 0), so we can capture the monitors in other quadrants. BUG= chromium:715689 Review-Url: https://codereview.webrtc.org/2848443004 Cr-Commit-Position: refs/heads/master@{#17935} [modify] https://crrev.com/049ec71e657eef3d15e0f15d60acb1a71e81b521/webrtc/modules/desktop_capture/win/dxgi_adapter_duplicator.cc [modify] https://crrev.com/049ec71e657eef3d15e0f15d60acb1a71e81b521/webrtc/modules/desktop_capture/win/dxgi_adapter_duplicator.h [modify] https://crrev.com/049ec71e657eef3d15e0f15d60acb1a71e81b521/webrtc/modules/desktop_capture/win/dxgi_duplicator_controller.cc [modify] https://crrev.com/049ec71e657eef3d15e0f15d60acb1a71e81b521/webrtc/modules/desktop_capture/win/dxgi_duplicator_controller.h [modify] https://crrev.com/049ec71e657eef3d15e0f15d60acb1a71e81b521/webrtc/modules/desktop_capture/win/dxgi_output_duplicator.cc [modify] https://crrev.com/049ec71e657eef3d15e0f15d60acb1a71e81b521/webrtc/modules/desktop_capture/win/dxgi_output_duplicator.h
,
Apr 28 2017
The following revision refers to this bug: https://chromium.googlesource.com/external/webrtc.git/+/7aea6afdab29f07c8cd3022529a14894ca294811 commit 7aea6afdab29f07c8cd3022529a14894ca294811 Author: zijiehe <zijiehe@chromium.org> Date: Fri Apr 28 21:30:56 2017 Revert of Allow Windows to return a monitor out of the first quadrant (patchset #2 id:60001 of https://codereview.chromium.org/2848443004/ ) Reason for revert: TranslateRect() is placed in a wrong position. Original issue's description: > Allow Windows to return a monitor out of the first quadrant > > Windows may return a DesktopCoordinate out of the first quadrant > (x >= 0 && y >= 0), this typically happens when the primary and secondary > monitors are swapped. i.e. The secondary monitor is on the left but the primary > one is on the right. > This change "moves" the entire screen from any quadrant to the (0, 0), so we can > capture the monitors in other quadrants. > > BUG= chromium:715689 > > Review-Url: https://codereview.webrtc.org/2848443004 > Cr-Commit-Position: refs/heads/master@{#17935} > Committed: https://chromium.googlesource.com/external/webrtc/+/049ec71e657eef3d15e0f15d60acb1a71e81b521 TBR=sergeyu@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= chromium:715689 Review-Url: https://codereview.webrtc.org/2852783002 Cr-Commit-Position: refs/heads/master@{#17936} [modify] https://crrev.com/7aea6afdab29f07c8cd3022529a14894ca294811/webrtc/modules/desktop_capture/win/dxgi_adapter_duplicator.cc [modify] https://crrev.com/7aea6afdab29f07c8cd3022529a14894ca294811/webrtc/modules/desktop_capture/win/dxgi_adapter_duplicator.h [modify] https://crrev.com/7aea6afdab29f07c8cd3022529a14894ca294811/webrtc/modules/desktop_capture/win/dxgi_duplicator_controller.cc [modify] https://crrev.com/7aea6afdab29f07c8cd3022529a14894ca294811/webrtc/modules/desktop_capture/win/dxgi_duplicator_controller.h [modify] https://crrev.com/7aea6afdab29f07c8cd3022529a14894ca294811/webrtc/modules/desktop_capture/win/dxgi_output_duplicator.cc [modify] https://crrev.com/7aea6afdab29f07c8cd3022529a14894ca294811/webrtc/modules/desktop_capture/win/dxgi_output_duplicator.h
,
Apr 28 2017
,
Apr 28 2017
,
Apr 28 2017
The following revision refers to this bug: https://chromium.googlesource.com/external/webrtc.git/+/419c7427153f3e72ff2a0edf799faf3b1f07c845 commit 419c7427153f3e72ff2a0edf799faf3b1f07c845 Author: zijiehe <zijiehe@chromium.org> Date: Fri Apr 28 23:08:20 2017 Allow Windows to return a monitor out of the first quadrant Windows may return a DesktopCoordinate out of the first quadrant (x >= 0 && y >= 0), this typically happens when the primary and secondary monitors are swapped. i.e. The secondary monitor is on the left but the primary one is on the right. This change "moves" the entire screen from any quadrant to the (0, 0), so we can capture the monitors in other quadrants. BUG= chromium:715689 Review-Url: https://codereview.webrtc.org/2848443004 Cr-Original-Commit-Position: refs/heads/master@{#17935} Committed: https://chromium.googlesource.com/external/webrtc/+/049ec71e657eef3d15e0f15d60acb1a71e81b521 Review-Url: https://codereview.webrtc.org/2848443004 Cr-Commit-Position: refs/heads/master@{#17938} [modify] https://crrev.com/419c7427153f3e72ff2a0edf799faf3b1f07c845/webrtc/modules/desktop_capture/win/dxgi_adapter_duplicator.cc [modify] https://crrev.com/419c7427153f3e72ff2a0edf799faf3b1f07c845/webrtc/modules/desktop_capture/win/dxgi_adapter_duplicator.h [modify] https://crrev.com/419c7427153f3e72ff2a0edf799faf3b1f07c845/webrtc/modules/desktop_capture/win/dxgi_duplicator_controller.cc [modify] https://crrev.com/419c7427153f3e72ff2a0edf799faf3b1f07c845/webrtc/modules/desktop_capture/win/dxgi_duplicator_controller.h [modify] https://crrev.com/419c7427153f3e72ff2a0edf799faf3b1f07c845/webrtc/modules/desktop_capture/win/dxgi_output_duplicator.cc [modify] https://crrev.com/419c7427153f3e72ff2a0edf799faf3b1f07c845/webrtc/modules/desktop_capture/win/dxgi_output_duplicator.h
,
Apr 28 2017
change in #c23 needs to be merged to WebRTC/59.
,
Apr 29 2017
This bug requires manual review: Reverts referenced in bugdroid comments after merge request. Please contact the milestone owner if you have questions. Owners: amineer@(Android), cmasso@(iOS), gkihumba@(ChromeOS), Abdul Syed@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 1 2017
Just to clarify, there is a defect in original change https://chromium.googlesource.com/external/webrtc.git/+/049ec71e657eef3d15e0f15d60acb1a71e81b521, which has been reverted and addressed by change https://chromium.googlesource.com/external/webrtc.git/+/419c7427153f3e72ff2a0edf799faf3b1f07c845.
,
May 1 2017
Has this been tested in Canary? Is there enough automated test coverage around this?
,
May 2 2017
I have tested with my personal build, and the change fixes the issue described in this bug. But this change has not been merged to Canary 60.0.3086.0 yet. Do you prefer me to test it again tomorrow in Canary?
,
May 2 2017
Yes please - before merging in Beta, we have to test this in Canary first.
,
May 2 2017
,
May 2 2017
I do not quite know the rule to choose the version of third-party dependencies, but my change (in WebRTC) is not included in the latest canary 60.0.3087.0. I will keep tracking the canary updates.
,
May 3 2017
Issue 717366 has been merged into this issue.
,
May 3 2017
My change has been included in the canary 60.0.3088, https://chromium.googlesource.com/chromium/src/+/60.0.3088.0%5E%21/#F0. I have verified it fixes the issue mentioned in this bug.
,
May 3 2017
Is this a strict windows specific issue? I've seen some screen sharing fails on Mac dual monitor as well.
,
May 3 2017
Yes, the changed logic is for Windows only. I have almost no knowledge of Mac capturer, Sergey (SergeyU@) may be the right person to talk with.
,
May 3 2017
Approving merge for M59 based on comment 33.
,
May 3 2017
Just realized this change is not be able to merge to M59 because of change https://chromium.googlesource.com/external/webrtc/trunk/webrtc.git/+/1a761bedfce98ba790b83475a99bed5f1cfa9405. Abdul, what do we usually do under this kind of situation?
,
May 4 2017
Sorry I really mean https://chromium.googlesource.com/external/webrtc/+/cf5753df778c10ec1034076d1f315fd27fad183d. This change also needs to be merged to M59 to resolve the conflict. Otherwise we may need to wait for next release.
,
May 4 2017
Verified as fixed in 60.0.3088.3 (Official Build) canary (64-bit). Thanks a lot! Of course I'd appreciate very much if this fix could be merged to M59 since I'm not that keen on customers stating "your application crashes Chrome!"
,
May 4 2017
Yes, please make sure that this is fixed also in M59. Screen sharing is a main scenario which we cannot afford to just say wait another 6 weeks.
,
May 4 2017
Thank you for your comments, without these two changes, screen sharing is still functional well but with less efficiency. More background, DirectX capturer uses DirectX / DXGI to capture screen and supports features such as screen sharing. But due to the complexity of the API, we did find several edge cases break the capturer. I fixed them, and the change in #c23 is one of them.
,
May 4 2017
Change https://chromium.googlesource.com/external/webrtc/+/cf5753df778c10ec1034076d1f315fd27fad183d also needs to be merged to M59 to avoid conflict. Both changes have been tested on the canary already.
,
May 4 2017
re #c41 - Maybe we're talking at cross purposes, but I have to disagree with the "still functional". As stated in the original report, Chrome used to crash on me before your fixes. Or do you mean that you'd rather fall back to the previous capturer for M59? That would of course also be fine with me.
,
May 4 2017
This bug requires manual review: Reverts referenced in bugdroid comments after merge request. Please contact the milestone owner if you have questions. Owners: amineer@(Android), cmasso@(iOS), gkihumba@(ChromeOS), Abdul Syed@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 4 2017
Yes, without both changes merged, we will revert to use previous GDI capturer to avoid crashing.
,
May 4 2017
As confirmed over chat, both changes have been tested in canary, there is enough automated test coverage, and are safe merges. Please go ahead and merge to M59 3071.
,
May 4 2017
The following revision refers to this bug: https://chromium.googlesource.com/external/webrtc.git/+/61fe801ad874104a2d461083f53caee4c19c51b6 commit 61fe801ad874104a2d461083f53caee4c19c51b6 Author: Zijie He <zijiehe@chromium.org> Date: Thu May 04 18:26:35 2017 Allow Windows to return a monitor out of the first quadrant Windows may return a DesktopCoordinate out of the first quadrant (x >= 0 && y >= 0), this typically happens when the primary and secondary monitors are swapped. i.e. The secondary monitor is on the left but the primary one is on the right. This change "moves" the entire screen from any quadrant to the (0, 0), so we can capture the monitors in other quadrants. BUG= chromium:715689 Review-Url: https://codereview.webrtc.org/2848443004 Cr-Original-Commit-Position: refs/heads/master@{#17935} Committed: https://chromium.googlesource.com/external/webrtc/+/049ec71e657eef3d15e0f15d60acb1a71e81b521 Review-Url: https://codereview.webrtc.org/2848443004 Cr-Commit-Position: refs/heads/master@{#17938} (cherry picked from commit 419c7427153f3e72ff2a0edf799faf3b1f07c845) Review-Url: https://codereview.webrtc.org/2866493002 . Cr-Commit-Position: refs/branch-heads/59@{#9} Cr-Branched-From: 10d095d4f743bc16f8e486e156c48a6d023b32c5-refs/heads/master@{#17657} [modify] https://crrev.com/61fe801ad874104a2d461083f53caee4c19c51b6/webrtc/modules/desktop_capture/win/dxgi_adapter_duplicator.cc [modify] https://crrev.com/61fe801ad874104a2d461083f53caee4c19c51b6/webrtc/modules/desktop_capture/win/dxgi_adapter_duplicator.h [modify] https://crrev.com/61fe801ad874104a2d461083f53caee4c19c51b6/webrtc/modules/desktop_capture/win/dxgi_duplicator_controller.cc [modify] https://crrev.com/61fe801ad874104a2d461083f53caee4c19c51b6/webrtc/modules/desktop_capture/win/dxgi_duplicator_controller.h [modify] https://crrev.com/61fe801ad874104a2d461083f53caee4c19c51b6/webrtc/modules/desktop_capture/win/dxgi_output_duplicator.cc [modify] https://crrev.com/61fe801ad874104a2d461083f53caee4c19c51b6/webrtc/modules/desktop_capture/win/dxgi_output_duplicator.h
,
May 4 2017
Thank you Abdul. Both changes are merged to WebRTC/59. https://codereview.chromium.org/2860573010/ https://codereview.chromium.org/2866493002/ Remove Merge-Approved-59.
,
May 4 2017
I am tracking the M59 beta. Once I confirmed this fix is in and addresses the issue, I will resolve this issue as fixed.
,
May 4 2017
,
May 8 2017
This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible! If all merges have been completed, please remove any remaining Merge-Approved labels from this issue. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 8 2017
Remove Merge-Approved-59.
,
May 10 2017
Verified the change on beta 59.0.3071.47: it works well. I will mark this issue as fixed. Please feel free to reopen it if you still encounter any similar issues. Thank you.
,
May 11 2017
Verified fixed in beta 59.0.3071.47. Thanks again - well done! |
||||||||||||||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||||||||||||||
Comment 1 by ajha@chromium.org
, Apr 27 2017