Regression: Black screen appears on capturing desktop from 'Awesome Screenshot' extension
Reported by
khushal....@etouch.net,
May 8 2018
|
|||||
Issue descriptionChrome Version: 68.0.3424.0 (Official Build) Revision 7b31b2ed3f03336596e6193a8e93fd961bd06c03-refs/branch-heads/3424@{#1} (32/64-bit) OS: Win (7, 8, 8.1, 10), Mac (10.12.6, 10.13.1, 10.13.5) and Linux (14.04 LTS). Test URL: https://chrome.google.com/webstore/detail/awesome-screenshot-screen/nlipoenfbbikpbjkfpfillcgkoblgpmj?utm_source=chrome-ntp-icon Steps to reproduce: 1. Launch chrome, navigate to above URL and add the extension. 2. Now click on the extension and select the "Capture desktop" option from the list and observe the new tab screen. Actual Result: Black screen appears on capturing desktop from 'Awesome Screenshot' extension. Expected Result: Screenshot should appear on capturing desktop from 'Awesome Screenshot' extension. This is Regression issue broken in 'M-67’ and providing the bisect using per-bisect revision: Good Build: 67.0.3375.0 (Revision: 543962) Bad Build: 67.0.3377.0 (Revision: 544610) You are probably looking for a change made after 544420 (known good), but no later than 544421 (first known bad). CHANGE-LOG URL: The script might not always return single CL as suspect as some perf builds might get missing due to failure. https://chromium.googlesource.com/chromium/src/+log/de61e03fab208d9dc380ea44430b4c8fbf92ad3f..81866e04ef43113fc195c539b291dd4d95a3d341 Suspect: https://chromium.googlesource.com/chromium/src/+/81866e04ef43113fc195c539b291dd4d95a3d341 @guidou: Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner. Note: Issue is also seen on M-67 Beta (build #67.0.3396.30) and M-68 Dev (build #68.0.3418.2). Kindly refer attached screen cast. Thank You..!!
,
May 8 2018
Also, it would be good to try with the --autoplay-policy=no-user-gesture-required command-line switch, in case this is using an autoplayed element that is paused by the default autoplay policy.
,
May 9 2018
With respect to comment #2, Recheched the above issue on Win7 OS using --autoplay-policy=no-user-gesture-required command, and the issue still exist on latest canary build #68.0.3425.0 Please refer the attached screen cast.
,
May 14 2018
AFAICT, it looks like the extension is using a video element, but it is not invoking the play() method, so the element is paused and nothing is played. r544421 fixes a bug where paused video elements playing a MediaStream actually rendered frames. This might be the reason this was working prior to r544421. khushal.pawar@etouch.net: Can you confirm?
,
May 15 2018
khushal.pawar@etouch.net: It is confirmed that the extension does not work because of r544421, so it makes sense that it works at r544415 and it does not work at r544427. I even confirmed it myself by locally reintroducing the bug that r544421 fixed. The problem seems to be that the extension is using a media element that is paused and therefore it does not render anything. I just wanted you to check the extension code and confirm that this is indeed the case so as to close this bug.
,
May 15 2018
,
May 17 2018
CLosing this as WontFix since this is almost certainly a problem with the extension, which was relying on a previous bug in Chrome. The fix would be to call the play() method on the paused video element. khushal.pawar@etouch.net: Please reopen if find out that this is not the case. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by guidou@chromium.org
, May 8 2018