Closed
Bug 1469863
Opened 6 years ago
Closed 6 years ago
The name and content of shared windows are not displayed using https://mozilla.github.io/webrtc-landing/gum_test.html
Categories
(Core :: WebRTC, defect, P3)
Tracking
()
RESOLVED
DUPLICATE
of bug 1318702
People
(Reporter: roxana.leitan, Assigned: dminor)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
259.59 KB,
video/mp4
|
Details |
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0 Build ID: 20180619220118 [Affected versions]: Nightly 62.0a1 [Affected platforms]: Windows 10 x64 [Steps to reproduce]: 1.Launch Firefox with a new profile 2.Open another browser with a few tabs open in it 3.Go to Firefox and open https://mozilla.github.io/webrtc-landing/gum_test.html 4.Go to the other browser and open a new tab 5.Go to Firefox and click "Window" button 6.Click to open the "Window to share" dropdown 7.Click the blank space option [Expected result]: All available windows should be listed with their name The selected window content should be correctly displayed [Actual result]: The content of the selected window is not displayed (black screen) [Note]: The issue is intermittent The issue is not reproducible after reloading https://mozilla.github.io/webrtc-landing/gum_test.html page
Could you help clarify some of the steps? For step 4 should the other browser be Firefox, something else, or it doesn't matter? For the Chrome case I do seem to have consistent issues when trying to capture Chrome windows (same blank capture). Though in that case reloading the gum page doesn't seem to help. ni :dminor to check my working on the priority. Please let me know if I should ni someone else in future for window capture bugs.
Flags: needinfo?(dminor)
Priority: -- → P3
Assignee | ||
Comment 2•6 years ago
|
||
We do have some known issues with window capture on windows where we are unable to capture some windows depending upon the graphics API used to render them. I think there is also a timing issue where a window will not show up in the list if it is opened after the window sharing door hanger is opened. It sounds like Bryce may have been hitting the first issue and Roxana the second. It doesn't look like we have open bugs for either of these problems. I'll do some testing and file as appropriate.
(In reply to Bryce Van Dyk (:bryce) from comment #1) > Could you help clarify some of the steps? For step 4 should the other > browser be Firefox, something else, or it doesn't matter? For the Chrome > case I do seem to have consistent issues when trying to capture Chrome > windows (same blank capture). I reproduced the issue using Chrome Though in that case reloading the gum page > doesn't seem to help. > I retested and the issue persisted after browser reload. The issue is reproducible also on Firefox Release 60.0.2 and Firefox Beta 61.0b14.
Assignee | ||
Comment 4•6 years ago
|
||
Windows not refreshing until after a browser reload is Bug 1325397. Refreshing the list without a reload is not part of the spec and may have privacy implications. Not being able to share a Google Chrome window looks like it has already been filed as Bug 1318702, although as mentioned above, it is not just Chrome windows which are problematic. I'm going to mark this as a duplicate of Bug 1318702.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•