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)

x86_64
Windows 10
defect

Tracking

()

RESOLVED DUPLICATE of bug 1318702
Tracking Status
firefox60 --- affected
firefox61 --- affected
firefox62 --- affected

People

(Reporter: roxana.leitan, Assigned: dminor)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Attached video 2018-06-20_16h01_18.mp4
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
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.
Assignee: nobody → dminor
Flags: needinfo?(dminor)
(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.
Version: 62 Branch → Trunk
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.

Attachment

General

Creator:
Created:
Updated:
Size: