Chromium

[Empty comment from Monorail migration]

[Monorail components: Blink>MemoryAllocator]

Tested the issue on reported chrome version #103.0.5060.114 using windows 11 as per https://crbug.com/chromium/1341878#c0

Steps to reproduce:
1.Launched Chrome
2.Opened given link: https://www.dptechnologies.cz/en and opened Inspect>>Dev tools
3.Resizing the website and observed 2000mb memory utilisation and GPU as 14.6% approximately

Attaching screencast for reference

Reporter@: Could you please review the attached screencast and let us know if anything being missed here.

Thanks..!!

@vasanthip@chromium.org Please watch the Memory and GPU tab in Performance section, especially these two values marked on screenshot - this memory is reserved and cannot be used by any other app. And maybe set the Task manager Always on top so you can resize the website fully.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

@vasanthip@chromium.org And you can also check built in Chrome Task Manager, occupied memory column on GPU Process https://www.youtube.com/watch?v=mh-GZPZBhw8. It goes up from 1,5 to 13+ GB in my case.

Tested the issue on chrome version #103.0.5060.114 using Windows 11 as per https://crbug.com/chromium/1341878#c3,4 and unable to reproduce the issue. Observed memory utilised 144,288k and GPU memory utilised 42,784k approximately. Hence marking this as untriaged and requesting someone from the Dev team to look into this for further inputs.

Thanks..!!

@vasanthip@chromium.org I found out that this problem occures only at higher screen resolution. In 1920x1080 there is no problem at all, in 2560x1440 there is already noticable gain in memory usage and in 3840x2160 and higher it is insane.
I understand that higher resolution needs more resources, but this is way too much, Firefox uses only 2 - 3 more gigs at 5120x2880 resolution and runs smoothly as you can see on videos i linked in first post.

So who is responsible for such memory leaks in higher resolution? And who is going to buy me 64 GB of RAM since 32 GB is not enough for front-end development in Chromium based browsers? This should be compatible with my board https://www.gskill.com/qvl/165/166/1562839932/F4-3600C16Q-64GTZR-QVL. Thanks.

You can close this, i fixed it by myself. Switched to Firefox and the problem is gone.

Tentatively adding Internals>Core component and requesting someone from the Dev team to look into this for further inputs.

Thanks..!!

[Monorail components: Internals>Core]

[Empty comment from Monorail migration]

[Monorail components: -Blink>MemoryAllocator Internals>GPU]

[Empty comment from Monorail migration]

This reproduced on canary 122.0.6234.0 on macOS. Report was from Windows.

This particular page has an SVG image.

During a resize of a Renderer we do keep interim frames alive in the GPU. So that if a complex page takes too long to relayout/render we can display the previous size in the interim.

These are supposed to be freed when replaced. However this reproduction does keep graphics memory around. We should take a chrome memory-infra trace to determine which allocations aren't being released, and why.

[Monorail components: -Internals>Core Blink>SVG Internals>Services>Viz]

This issue was migrated from crbug.com/chromium/1341878?no_tracker_redirect=1

[Multiple monorail components: Blink>SVG, Internals>GPU, Internals>Services>Viz]
[Monorail components added to Component Tags custom field.]

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

[Monorail components: Internals>Permissions>Model]

[Empty comment from Monorail migration]

[Monorail components: -Internals>Permissions>Model UI>Browser>Permissions>Prompts]

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

niklase@, is this on the roadmap? It seems like this is the reason that https://developer.chrome.com/extensions/desktopCapture exists, and a problem for any site that can't convince users to install an extension.

https://w3c.github.io/mediacapture-screen-share/ exists (mentioned above) but is it being implemented in any other browser?

Firefox use an API that's much closer to the w3c spec, not sure if it's 100% compliant or not. We want to move over to this API but we're not actively working on it yet. Afaik all spec discussions are on hold since this is not considered part of WebRTC 1.0.

Do you what the APIs are called for that? I just looked for 'getDisplayMedia' and couldn't find anything in Gecko.

niklase@, can you set a next action date for this? Having many stars, being assigned and a P2, one could easily get the impression that it's planned work.

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

Two questions:
1. Since https://crbug.com/chromium/830832 was merged here, can we expect to be able to screen capture without extensions after the current issue is fixed?
2. Is there any sort of estimation about when the current issue will be fixed?

As of the Windows April 2018 Update (released 30th of April), Edge now implements getDisplayMedia (https://blogs.windows.com/msedgedev/2018/04/30/edgehtml-17-april-2018-update/) :)

Is this still blocked on https://crbug.com/webrtc/1757? They seem unrelated to me, now that getDisplayMedia is covered in its own specification :)

[Empty comment from Monorail migration]

What's the description/goal of this issue nowadays? Surely it has changed a bit in the last 4.5 years, especially with https://crbug.com/webrtc/1757 and https://crbug.com/chromium/830832 being merged into this. Can this issue be considered to be of type Feature (with a description more similar to https://crbug.com/chromium/830832), instead of type Bug? Also, is implementing getDisplayMedia (a.k.a. the Screen Share API) considered a solution to this specific issue? :)

[Empty comment from Monorail migration]

In light of the recent announcement[1] from James Wagner, disclosing that inline installations of Chrome Extensions will now be soon be completely disabled, I would claim that the urgency of this issue is particularly high.

Some extra words for context: Chrome only permits screen capture when initiated from an extension. Without inline installations it is impossible to install a chrome extension in a seamless, user-friendly manner. Hence, it is now significantly more difficult, if not impossible, for websites to provide screen capture to Chrome-users while maintaining any sort of respect towards the user experience. Having to install third-party software is something that most users are (rightfully) hesitant towards. One of the fantastic things about the web is the concept of users not having to install extra software for every product - this needs to be the case for screen capture on chrome as well! :)

[1] https://blog.chromium.org/2018/06/improving-extension-transparency-for.html

huib/blum: can you please explain
1) why one has to learn about this here
2) how the migration is supposed to work given that getDisplayMedia is not implemented.

Regarding https://crbug.com/chromium/326740#c33, the goal is to ship getDisplayMedia in Chrome. We don't yet have an exact timetable to share, but understand the urgency here.

[Comment Deleted]

> 1) why one has to learn about this here

If you'll allow me, and if I'd have to guess, it's because Google Meet (previously Google Hangouts) gets special treatment from Google.

In particular, Chrome doesn't require an extension to use screensharing from Google Meet (I won't get into the antitrust ramifications of this matter, let's just say it's not really fair to other products).

In other words, Google doesn't care enough about screensharing usecases other than Google Meet's. Otherwise:

1) They wouldn't had communicated the removal of inline installations so poorly and without an alternative.

2) They would had removed the need of an extension for screensharing long ago, just like Mozilla did in Firefox. Instead, Google is adding even more friction by disabling inline installations of the screensharing extensions.

> 2) how the migration is supposed to work given that getDisplayMedia is not implemented.

I would be happy to be proven wrong and be shown an alternative, but at this point I think that the only two options are living with it or fixing the current issue.

The original rationale for Chrome's approach is stated in https://tools.ietf.org/html/draft-ietf-rtcweb-security-10#section-4.1.1. We are looking at how to expose sharing more generally while still addressing the listed threats.

Arguably, an extension (inline or not) is overkill to address those threats (just like it would for accepting the use of a audio/video).

Then again, I am sure Google would had expedited the process if Hangouts was exposed to that sort of onboarding friction.

The linked section details how this is distinct from regular audio and video.

How does Google Meet get around the problem and can that be opened up to other screen sharing users? (Sorry, didn't have time to debug Meet)

#43, Google Meet has a pre-installed extension in Chrome (not chromium though). Any web service can provide their own extension today, but it has to be installed by the end user.

Just adding to the frustration here, but removing inline installation will be a huge barrier for users to understand, and even today inline installation is giving us problems from "non-technical" users. Having to redirect them to a poorly designed (sorry, but it looks horrible by today's standards) extensions page to have them click stuff there outside our control, then return to our webapp is completely unacceptable.

I mean, the extensions page looks fishy at best, and it provides no context to the user of their original action and what they need to do next, making it very hard to convince them to click install and return to our page to share their screen (our users have enough problems understanding the concept of tabs, let alone extensions and their ramifications to the end-user experience).

This is just another move from Chrome that shits on WebRTC developers with no mention of us or acceptable workarounds in the time frame given until release.

> The linked section details how this is distinct from regular audio and video.

I understand that. It doesn't make less true that requiring an explicit extension is overkill and that Google would had found a better solution if Meet/Hangouts was exposed to the same onboarding friction as the res of WebRTC application developers.

It's Ironic how WebRTC stemmed from removing the need of an plugin for Google Talk and yet Chrome added the need of an extension.

I think both the blog and referenced RFC makes some good points. But if Google/Chromes stance wants to be taken seriously on this issue, the Google Meet should not be preinstalled until those concerns are addressed IMO. Because some of those issues clearly are not addressed by Google Meet anymore than they are by an installed extension.

I'd like to double down on this one. I also reached out to James following the announcement as I believe a better solution for screen share should have been implemented before deprecation of the in-line install flow. The threats mentioned are still limited when considering the high visibility of the display/window picker and the fact that Firefox and Edge have shipped this without additional consent.

As mentioned in https://crbug.com/chromium/326740#c37, we intent to ship getDisplayMedia in Chrome. Announcement here: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/j7k2nI_9nng

I second concerns from #46 - we're reliant on inline installation for a decent UX. Otherwise, especially for one time use users (think customer service) it's a huge pain to have them go download extensions manually. getDisplayMedia would be great, but to have a big gap between inline installation and getDisplayMedia is harmful to existing apps. The allowance for already-published extensions should extend until getDisplayMedia is ready, without a need for an extension, and enabled by default.

[Comment Deleted]

[Comment Deleted]

https://www.chromestatus.com/feature/6744724455030784
Firefox Shipped?

Firefox shipped this API a long time ago.

[Comment Deleted]

#55
In Firefox, neither navigator.getDisplayMedia() nor navigator.mediaDevices.getDisplayMedia(), can be found.
Will it be effective with any flags?

Hmm. The tutorial points to using

navigator.mediaDevices.getUserMedia({
  video: {
    mediaSource: 'screen'
  }
})


Is this one of the divergences between the implementation and the spec that the bug points to? The bug isn't explicit enough to be sure.

If i'm not mistaken, while chromium just announced intent to ship getDisplayMedia (https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/j7k2nI_9nng), but:

Activation

Polyfill on top of the existing functionality may be possible, but still requires using an extension for enabling.

<-- even if getDisplayMedia will be added, an extension would still be required ? Or is that just for the getUserMedia polyfill fallback ? Can anyone clearly confirm that shipping getDisplayMedia will also remove the need for extensions alltogether ?

#61 - it will be a totally normal web API, without extensions, only permissions (as usual for powerful features like getUserMedia and so on).
Also, it is not an intent to ship, but only an intent to implement.

Attaching a screenshot of how Firefox's screen sharing dialog looks like.

Can someone explain why it matters what the UI looks like in Firefox? Or why Firefox is even being discussed? Firefox has not implemented or shipped getDisplayMedia, it implements getUserMedia with an option to capture the screen, just like Chrome does today, the difference being that it doesn't require an extension.

The key point is our intent to implement getDisplayMedia: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/j7k2nI_9nng

There are some outstanding questions regarding securing access to this API, but we are aware that both Firefox and Edge support some form of screen capture for the general web and intend to do the same.

#65: How are you going to resolve that getDisplayMedia
1) does not address audio sharing which chooseDesktopMedia does
2) does not allow restricting the display surfaces the same way chooseDesktopMedia does -- reordering was just shipped in M61 so there must be some use-case for that
3) spec-wise still calls for elevated privileges (such as an extension) for tab sharing

Reducing the initial scope to the equivalent of ['screen', 'window'] might be an option if that means you can ship soon enough.

re #65 1): Doesn't getDisplayMedia offer {audio: true}?
Never mentioned in the spec (that's a bug), but the syntax seems to allow it.

#67: I do not find the mediacapture-screen-share very clear on this or in general. It lacks the precise step-by-step descriptions of mediacapture-main or webrtc-pc.

Some of the open questions I have like "how to specify framerate" will be resolved when https://github.com/w3c/mediacapture-screen-share/issues/49 is done at least.

[Empty comment from Monorail migration]

I'd like to add to the growing chorus of not breaking inline installation until this is fixed. We rely on this for Highfive, and just like appear.in and others have already stated, this will break UX for all of our Chrome users.

If that's not possible, at least allow inline installation for already-published extensions that grant screen share permissions.

#70: We are evaluating what can be done until gDM ships.

Not an answer to #70 - but there is now a shim in adapter.js that allows you to start using the getDisplayMedia API with your current plugin-based solution. (It requires you to enable the shimming and supply a linkage function).

This might be useful in order to make sure your code continues to work smoothly once the interface ships.

[Empty comment from Monorail migration]

niklase: can you consider making https://crbug.com/chromium/865060 public please?

Re #74, it's just an empty launch bug to check off internal reviews and milestones. They are not public but all details should go into this bug.

[Empty comment from Monorail migration]

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c8ce6bcf304347e03fd7448966ae028e1d90bcae

commit c8ce6bcf304347e03fd7448966ae028e1d90bcae
Author: Emircan Uysaler <emircan@chromium.org>
Date: Fri Aug 03 18:45:02 2018

Pass stream source as MediaStreamType in TrackControls

This CL completes a TODO in media_stream_controls.h, by switching from
std::string to MediaStreamType. Accordingly, it changes related mojo files,
renderer side UserMediaProcessor and browser side MediaStreamManager.

This will let us add new MediaStreamTypes for request in follow-up CLs.

Bug: 326740
Change-Id: I13e2613c190d342c95f084b3a06933a9458a12a8
Reviewed-on: https://chromium-review.googlesource.com/1159839
Reviewed-by: Will Harris <wfh@chromium.org>
Reviewed-by: Christian Fremerey <chfremer@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Sergey Ulanov <sergeyu@chromium.org>
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Commit-Queue: Emircan Uysaler <emircan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#580613}
[modify] https://crrev.com/c8ce6bcf304347e03fd7448966ae028e1d90bcae/chrome/browser/media/webrtc/media_capture_devices_dispatcher.cc
[modify] https://crrev.com/c8ce6bcf304347e03fd7448966ae028e1d90bcae/content/browser/renderer_host/media/media_stream_dispatcher_host_unittest.cc
[modify] https://crrev.com/c8ce6bcf304347e03fd7448966ae028e1d90bcae/content/browser/renderer_host/media/media_stream_manager.cc
[modify] https://crrev.com/c8ce6bcf304347e03fd7448966ae028e1d90bcae/content/browser/renderer_host/media/media_stream_ui_proxy.cc
[modify] https://crrev.com/c8ce6bcf304347e03fd7448966ae028e1d90bcae/content/common/media/media_stream.mojom
[modify] https://crrev.com/c8ce6bcf304347e03fd7448966ae028e1d90bcae/content/common/media/media_stream_controls.cc
[modify] https://crrev.com/c8ce6bcf304347e03fd7448966ae028e1d90bcae/content/common/media/media_stream_controls.h
[modify] https://crrev.com/c8ce6bcf304347e03fd7448966ae028e1d90bcae/content/common/media/media_stream_typemap_traits.cc
[modify] https://crrev.com/c8ce6bcf304347e03fd7448966ae028e1d90bcae/content/common/media/media_stream_typemap_traits.h
[modify] https://crrev.com/c8ce6bcf304347e03fd7448966ae028e1d90bcae/content/public/common/media_stream_request.cc
[modify] https://crrev.com/c8ce6bcf304347e03fd7448966ae028e1d90bcae/content/public/common/media_stream_request.h
[modify] https://crrev.com/c8ce6bcf304347e03fd7448966ae028e1d90bcae/content/renderer/media/stream/media_stream_constraints_util_audio_unittest.cc
[modify] https://crrev.com/c8ce6bcf304347e03fd7448966ae028e1d90bcae/content/renderer/media/stream/media_stream_constraints_util_video_content.cc
[modify] https://crrev.com/c8ce6bcf304347e03fd7448966ae028e1d90bcae/content/renderer/media/stream/media_stream_constraints_util_video_content.h
[modify] https://crrev.com/c8ce6bcf304347e03fd7448966ae028e1d90bcae/content/renderer/media/stream/media_stream_constraints_util_video_content_unittest.cc
[modify] https://crrev.com/c8ce6bcf304347e03fd7448966ae028e1d90bcae/content/renderer/media/stream/media_stream_device_observer.cc
[modify] https://crrev.com/c8ce6bcf304347e03fd7448966ae028e1d90bcae/content/renderer/media/stream/media_stream_source.cc
[modify] https://crrev.com/c8ce6bcf304347e03fd7448966ae028e1d90bcae/content/renderer/media/stream/media_stream_source.h
[modify] https://crrev.com/c8ce6bcf304347e03fd7448966ae028e1d90bcae/content/renderer/media/stream/user_media_processor.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/59bda766e3e1e9e8eb12b4c1b6cd2f1660f058f9

commit 59bda766e3e1e9e8eb12b4c1b6cd2f1660f058f9
Author: Emircan Uysaler <emircan@chromium.org>
Date: Fri Aug 03 22:59:37 2018

Reorganize MediaStreamType enums

This CL does two things(although looking huge):
- Adds a new MediaStreamType to specify getDisplayMedia() requests.(PS#2)
- Renames existing MEDIA_TAB* and MEDIA_DESKTOP* enums by adding
GUM to their name to distinguish these cases that originate from
calls to extension APIs and getUserMedia().(PS#1)

Bug: 326740
Change-Id: I1c4b47f1cb6c2fed478dcd265f9b1d9525efb4cb
Reviewed-on: https://chromium-review.googlesource.com/1160000
Commit-Queue: Emircan Uysaler <emircan@chromium.org>
Reviewed-by: Will Harris <wfh@chromium.org>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Sergey Ulanov <sergeyu@chromium.org>
Reviewed-by: Christian Fremerey <chfremer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#580686}
[modify] https://crrev.com/59bda766e3e1e9e8eb12b4c1b6cd2f1660f058f9/chrome/browser/extensions/api/tab_capture/offscreen_tab.cc
[modify] https://crrev.com/59bda766e3e1e9e8eb12b4c1b6cd2f1660f058f9/chrome/browser/extensions/api/tab_capture/tab_capture_registry.cc
[modify] https://crrev.com/59bda766e3e1e9e8eb12b4c1b6cd2f1660f058f9/chrome/browser/media/capture_access_handler_base.cc
[modify] https://crrev.com/59bda766e3e1e9e8eb12b4c1b6cd2f1660f058f9/chrome/browser/media/cast_mirroring_service_host.cc
[modify] https://crrev.com/59bda766e3e1e9e8eb12b4c1b6cd2f1660f058f9/chrome/browser/media/public_session_tab_capture_access_handler.cc
[modify] https://crrev.com/59bda766e3e1e9e8eb12b4c1b6cd2f1660f058f9/chrome/browser/media/webrtc/desktop_capture_access_handler.cc
[modify] https://crrev.com/59bda766e3e1e9e8eb12b4c1b6cd2f1660f058f9/chrome/browser/media/webrtc/media_capture_devices_dispatcher.cc
[modify] https://crrev.com/59bda766e3e1e9e8eb12b4c1b6cd2f1660f058f9/chrome/browser/media/webrtc/media_stream_capture_indicator.cc
[modify] https://crrev.com/59bda766e3e1e9e8eb12b4c1b6cd2f1660f058f9/chrome/browser/media/webrtc/permission_bubble_media_access_handler.cc
[modify] https://crrev.com/59bda766e3e1e9e8eb12b4c1b6cd2f1660f058f9/chrome/browser/media/webrtc/screen_capture_infobar_delegate_android.cc
[modify] https://crrev.com/59bda766e3e1e9e8eb12b4c1b6cd2f1660f058f9/chrome/browser/media/webrtc/tab_capture_access_handler.cc
[modify] https://crrev.com/59bda766e3e1e9e8eb12b4c1b6cd2f1660f058f9/chrome/browser/resource_coordinator/tab_lifecycle_unit_unittest.cc
[modify] https://crrev.com/59bda766e3e1e9e8eb12b4c1b6cd2f1660f058f9/chrome/browser/ui/cocoa/tabs/tab_strip_controller_unittest.mm
[modify] https://crrev.com/59bda766e3e1e9e8eb12b4c1b6cd2f1660f058f9/components/mirroring/browser/single_client_video_capture_host_unittest.cc
[modify] https://crrev.com/59bda766e3e1e9e8eb12b4c1b6cd2f1660f058f9/components/offline_pages/content/background_loader/background_loader_contents_unittest.cc
[modify] https://crrev.com/59bda766e3e1e9e8eb12b4c1b6cd2f1660f058f9/content/browser/renderer_host/media/audio_input_delegate_impl.cc
[modify] https://crrev.com/59bda766e3e1e9e8eb12b4c1b6cd2f1660f058f9/content/browser/renderer_host/media/audio_input_device_manager.cc
[modify] https://crrev.com/59bda766e3e1e9e8eb12b4c1b6cd2f1660f058f9/content/browser/renderer_host/media/audio_input_device_manager_unittest.cc
[modify] https://crrev.com/59bda766e3e1e9e8eb12b4c1b6cd2f1660f058f9/content/browser/renderer_host/media/in_process_video_capture_device_launcher.cc
[modify] https://crrev.com/59bda766e3e1e9e8eb12b4c1b6cd2f1660f058f9/content/browser/renderer_host/media/media_stream_manager.cc
[modify] https://crrev.com/59bda766e3e1e9e8eb12b4c1b6cd2f1660f058f9/content/browser/renderer_host/media/media_stream_manager.h
[modify] https://crrev.com/59bda766e3e1e9e8eb12b4c1b6cd2f1660f058f9/content/browser/renderer_host/media/media_stream_manager_unittest.cc
[modify] https://crrev.com/59bda766e3e1e9e8eb12b4c1b6cd2f1660f058f9/content/browser/renderer_host/media/media_stream_ui_proxy_unittest.cc
[modify] https://crrev.com/59bda766e3e1e9e8eb12b4c1b6cd2f1660f058f9/content/browser/renderer_host/media/render_frame_audio_input_stream_factory.cc
[modify] https://crrev.com/59bda766e3e1e9e8eb12b4c1b6cd2f1660f058f9/content/browser/renderer_host/media/render_frame_audio_input_stream_factory_unittest.cc
[modify] https://crrev.com/59bda766e3e1e9e8eb12b4c1b6cd2f1660f058f9/content/browser/renderer_host/media/video_capture_manager.cc
[modify] https://crrev.com/59bda766e3e1e9e8eb12b4c1b6cd2f1660f058f9/content/common/media/media_stream.mojom
[modify] https://crrev.com/59bda766e3e1e9e8eb12b4c1b6cd2f1660f058f9/content/common/media/media_stream_typemap_traits.cc
[modify] https://crrev.com/59bda766e3e1e9e8eb12b4c1b6cd2f1660f058f9/content/public/common/media_stream_request.cc
[modify] https://crrev.com/59bda766e3e1e9e8eb12b4c1b6cd2f1660f058f9/content/public/common/media_stream_request.h
[modify] https://crrev.com/59bda766e3e1e9e8eb12b4c1b6cd2f1660f058f9/content/renderer/media/stream/media_stream_constraints_util_audio.cc
[modify] https://crrev.com/59bda766e3e1e9e8eb12b4c1b6cd2f1660f058f9/content/renderer/media/stream/media_stream_constraints_util_audio_unittest.cc
[modify] https://crrev.com/59bda766e3e1e9e8eb12b4c1b6cd2f1660f058f9/content/renderer/media/stream/media_stream_constraints_util_video_content.cc
[modify] https://crrev.com/59bda766e3e1e9e8eb12b4c1b6cd2f1660f058f9/content/renderer/media/stream/media_stream_constraints_util_video_content_unittest.cc
[modify] https://crrev.com/59bda766e3e1e9e8eb12b4c1b6cd2f1660f058f9/content/renderer/media/stream/media_stream_device_observer_unittest.cc
[modify] https://crrev.com/59bda766e3e1e9e8eb12b4c1b6cd2f1660f058f9/content/renderer/media/stream/user_media_processor.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6e7a3bc8c8de4acd7e0be6009c0421ed40225c13

commit 6e7a3bc8c8de4acd7e0be6009c0421ed40225c13
Author: Emircan Uysaler <emircan@chromium.org>
Date: Sat Aug 04 02:53:27 2018

Add blink code handling getDisplayMedia()

This is the first CL in adding getDisplayMedia() support in chromium. See the
bug and linked design doc for the detailed plan.

This CL adds getDisplayMedia() interface behind runtime enabled features flag
"GetDisplayMedia". This call will use the same call stack as getUserMedia() but
have different media request type and handling of constraints.
- Adds WebUserMediaRequest enums to differentiate this call.
- Adds specific handling of constraints in UserMediaRequest::Create(). As
defined in the spec, this accepts empty constraints.
- Currently ends up in a NotSupported error as chromium changes are landing.
- Adds first set of Layout Tests to check these expectations.

Intent To Implement:
https://groups.google.com/a/chromium.org/forum/#!msg/Blink-dev/j7k2nI_9nng/OE6IvgJyAQAJ

Bug: 326740
Change-Id: I03c54cab259a57db99449d9c4510c484f22c5b93
Reviewed-on: https://chromium-review.googlesource.com/1155942
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Guido Urdaneta <guidou@chromium.org>
Commit-Queue: Emircan Uysaler <emircan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#580733}
[add] https://crrev.com/6e7a3bc8c8de4acd7e0be6009c0421ed40225c13/third_party/WebKit/LayoutTests/fast/mediastream/getdisplaymedia.html
[modify] https://crrev.com/6e7a3bc8c8de4acd7e0be6009c0421ed40225c13/third_party/WebKit/LayoutTests/webexposed/global-interface-listing-expected.txt
[modify] https://crrev.com/6e7a3bc8c8de4acd7e0be6009c0421ed40225c13/third_party/blink/public/web/web_user_media_request.h
[modify] https://crrev.com/6e7a3bc8c8de4acd7e0be6009c0421ed40225c13/third_party/blink/renderer/modules/exported/web_user_media_request.cc
[modify] https://crrev.com/6e7a3bc8c8de4acd7e0be6009c0421ed40225c13/third_party/blink/renderer/modules/mediastream/BUILD.gn
[modify] https://crrev.com/6e7a3bc8c8de4acd7e0be6009c0421ed40225c13/third_party/blink/renderer/modules/mediastream/media_devices.cc
[modify] https://crrev.com/6e7a3bc8c8de4acd7e0be6009c0421ed40225c13/third_party/blink/renderer/modules/mediastream/media_devices.h
[add] https://crrev.com/6e7a3bc8c8de4acd7e0be6009c0421ed40225c13/third_party/blink/renderer/modules/mediastream/navigator_display_media.cc
[add] https://crrev.com/6e7a3bc8c8de4acd7e0be6009c0421ed40225c13/third_party/blink/renderer/modules/mediastream/navigator_display_media.h
[add] https://crrev.com/6e7a3bc8c8de4acd7e0be6009c0421ed40225c13/third_party/blink/renderer/modules/mediastream/navigator_display_media.idl
[modify] https://crrev.com/6e7a3bc8c8de4acd7e0be6009c0421ed40225c13/third_party/blink/renderer/modules/mediastream/user_media_client.cc
[modify] https://crrev.com/6e7a3bc8c8de4acd7e0be6009c0421ed40225c13/third_party/blink/renderer/modules/mediastream/user_media_request.cc
[modify] https://crrev.com/6e7a3bc8c8de4acd7e0be6009c0421ed40225c13/third_party/blink/renderer/modules/mediastream/user_media_request.h
[modify] https://crrev.com/6e7a3bc8c8de4acd7e0be6009c0421ed40225c13/third_party/blink/renderer/modules/modules_idl_files.gni
[modify] https://crrev.com/6e7a3bc8c8de4acd7e0be6009c0421ed40225c13/third_party/blink/renderer/platform/runtime_enabled_features.json5

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/54124ea89a23c5f1d3e9987c3631fb2e1a2ea1f0

commit 54124ea89a23c5f1d3e9987c3631fb2e1a2ea1f0
Author: Emircan Uysaler <emircan@chromium.org>
Date: Thu Aug 09 23:20:38 2018

Move desktop picker ui implementation out of extensions

This CL moves the picker UI triggered from extensions into
DesktopMediaPickerFactoryImpl which lives under
/chrome/browser/media. We are planning to use this common
implementation to trigger the same picker UI for getDisplayMedia().

Bug: 326740
Change-Id: Idb8b9d094ce55ecc8281c3db1f1acb0f5e3a24f1
Reviewed-on: https://chromium-review.googlesource.com/1169594
Commit-Queue: Emircan Uysaler <emircan@chromium.org>
Reviewed-by: Weiyong Yao <braveyao@chromium.org>
Reviewed-by: Sergey Ulanov <sergeyu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#581953}
[modify] https://crrev.com/54124ea89a23c5f1d3e9987c3631fb2e1a2ea1f0/chrome/browser/BUILD.gn
[modify] https://crrev.com/54124ea89a23c5f1d3e9987c3631fb2e1a2ea1f0/chrome/browser/extensions/api/desktop_capture/desktop_capture_apitest.cc
[modify] https://crrev.com/54124ea89a23c5f1d3e9987c3631fb2e1a2ea1f0/chrome/browser/extensions/api/desktop_capture/desktop_capture_base.cc
[modify] https://crrev.com/54124ea89a23c5f1d3e9987c3631fb2e1a2ea1f0/chrome/browser/extensions/api/desktop_capture/desktop_capture_base.h
[add] https://crrev.com/54124ea89a23c5f1d3e9987c3631fb2e1a2ea1f0/chrome/browser/media/webrtc/desktop_media_picker_factory.cc
[add] https://crrev.com/54124ea89a23c5f1d3e9987c3631fb2e1a2ea1f0/chrome/browser/media/webrtc/desktop_media_picker_factory.h
[add] https://crrev.com/54124ea89a23c5f1d3e9987c3631fb2e1a2ea1f0/chrome/browser/media/webrtc/desktop_media_picker_factory_impl.cc
[add] https://crrev.com/54124ea89a23c5f1d3e9987c3631fb2e1a2ea1f0/chrome/browser/media/webrtc/desktop_media_picker_factory_impl.h
[add] https://crrev.com/54124ea89a23c5f1d3e9987c3631fb2e1a2ea1f0/chrome/browser/media/webrtc/fake_desktop_media_picker_factory.cc
[add] https://crrev.com/54124ea89a23c5f1d3e9987c3631fb2e1a2ea1f0/chrome/browser/media/webrtc/fake_desktop_media_picker_factory.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0dd972a182128b6d74a07926e690c45e9d2e07d0

commit 0dd972a182128b6d74a07926e690c45e9d2e07d0
Author: Emircan Uysaler <emircan@chromium.org>
Date: Tue Aug 14 05:15:37 2018

Add MediaAccessHandler for getDisplayMedia()

This CL adds a new permission handler for getDisplayMedia(). It uses
DesktopMediaPickerFactoryImpl as common implementation to trigger the
same picker UI as extensions. It also adds unit test that exercises
the new code path.

Bug: 326740
Change-Id: I3007124226d2b017ba06877a1bbcc87f3bc2f9a3
Reviewed-on: https://chromium-review.googlesource.com/1163533
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Sergey Ulanov <sergeyu@chromium.org>
Reviewed-by: Xiangjun Zhang <xjz@chromium.org>
Reviewed-by: Weiyong Yao <braveyao@chromium.org>
Commit-Queue: Emircan Uysaler <emircan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#582835}
[modify] https://crrev.com/0dd972a182128b6d74a07926e690c45e9d2e07d0/chrome/browser/BUILD.gn
[modify] https://crrev.com/0dd972a182128b6d74a07926e690c45e9d2e07d0/chrome/browser/media/capture_access_handler_base.cc
[modify] https://crrev.com/0dd972a182128b6d74a07926e690c45e9d2e07d0/chrome/browser/media/capture_access_handler_base.h
[modify] https://crrev.com/0dd972a182128b6d74a07926e690c45e9d2e07d0/chrome/browser/media/media_access_handler.cc
[modify] https://crrev.com/0dd972a182128b6d74a07926e690c45e9d2e07d0/chrome/browser/media/media_access_handler.h
[modify] https://crrev.com/0dd972a182128b6d74a07926e690c45e9d2e07d0/chrome/browser/media/webrtc/desktop_capture_access_handler.cc
[modify] https://crrev.com/0dd972a182128b6d74a07926e690c45e9d2e07d0/chrome/browser/media/webrtc/desktop_capture_access_handler.h
[add] https://crrev.com/0dd972a182128b6d74a07926e690c45e9d2e07d0/chrome/browser/media/webrtc/desktop_capture_devices_util.cc
[add] https://crrev.com/0dd972a182128b6d74a07926e690c45e9d2e07d0/chrome/browser/media/webrtc/desktop_capture_devices_util.h
[add] https://crrev.com/0dd972a182128b6d74a07926e690c45e9d2e07d0/chrome/browser/media/webrtc/display_media_access_handler.cc
[add] https://crrev.com/0dd972a182128b6d74a07926e690c45e9d2e07d0/chrome/browser/media/webrtc/display_media_access_handler.h
[add] https://crrev.com/0dd972a182128b6d74a07926e690c45e9d2e07d0/chrome/browser/media/webrtc/display_media_access_handler_unittest.cc
[modify] https://crrev.com/0dd972a182128b6d74a07926e690c45e9d2e07d0/chrome/browser/media/webrtc/media_capture_devices_dispatcher.cc
[modify] https://crrev.com/0dd972a182128b6d74a07926e690c45e9d2e07d0/chrome/browser/media/webrtc/permission_bubble_media_access_handler.cc
[modify] https://crrev.com/0dd972a182128b6d74a07926e690c45e9d2e07d0/chrome/test/BUILD.gn
[modify] https://crrev.com/0dd972a182128b6d74a07926e690c45e9d2e07d0/content/public/common/media_stream_request.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b02b3aaebbfcd212d4d2a024ae0fcd58f0b54b5c

commit b02b3aaebbfcd212d4d2a024ae0fcd58f0b54b5c
Author: Emircan Uysaler <emircan@chromium.org>
Date: Tue Aug 14 05:27:08 2018

Handle MEDIA_DISPLAY_VIDEO_CAPTURE cases

This CL handles MEDIA_DISPLAY_VIDEO_CAPTURE cases specifically in browser-side
MediaStreamManager and renderer-side UserMediaProcessor. This allows us to
link these specific calls from blink to MediaAccessHandler.

Bug: 326740
Change-Id: If12f9fe92a8b0ed7b30b0cad4c3c7ab140537566
Reviewed-on: https://chromium-review.googlesource.com/1170344
Commit-Queue: Emircan Uysaler <emircan@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Christian Fremerey <chfremer@chromium.org>
Reviewed-by: Guido Urdaneta <guidou@chromium.org>
Cr-Commit-Position: refs/heads/master@{#582838}
[modify] https://crrev.com/b02b3aaebbfcd212d4d2a024ae0fcd58f0b54b5c/content/browser/renderer_host/media/media_stream_manager.cc
[modify] https://crrev.com/b02b3aaebbfcd212d4d2a024ae0fcd58f0b54b5c/content/browser/renderer_host/media/media_stream_manager.h
[modify] https://crrev.com/b02b3aaebbfcd212d4d2a024ae0fcd58f0b54b5c/content/browser/renderer_host/media/media_stream_manager_unittest.cc
[modify] https://crrev.com/b02b3aaebbfcd212d4d2a024ae0fcd58f0b54b5c/content/public/common/media_stream_request.cc
[modify] https://crrev.com/b02b3aaebbfcd212d4d2a024ae0fcd58f0b54b5c/content/renderer/media/stream/user_media_processor.cc
[modify] https://crrev.com/b02b3aaebbfcd212d4d2a024ae0fcd58f0b54b5c/content/renderer/media/stream/user_media_processor.h

[Empty comment from Monorail migration]

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5c7ba649624db0eebcdabcd6d0844c0c17ebd903

commit 5c7ba649624db0eebcdabcd6d0844c0c17ebd903
Author: Emircan Uysaler <emircan@chromium.org>
Date: Fri Aug 17 17:55:56 2018

Hook up fake-device and fake-ui flags for getdisplayMedia()

This CL hooks up use-fake-device-for-media-stream and
use-fake-ui-for-media-stream flags for getdisplayMedia() calls for enabling
testing in the future.
- Use fake-ui chooses a default device. If fake-device is specified, that takes
priority.
- Fake-device type can be modified by flag args.

Bug: 326740
Change-Id: I4e97941743fa2149f88bc3714beb4d833da42e48
Reviewed-on: https://chromium-review.googlesource.com/1177448
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Christian Fremerey <chfremer@chromium.org>
Commit-Queue: Emircan Uysaler <emircan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#584121}
[modify] https://crrev.com/5c7ba649624db0eebcdabcd6d0844c0c17ebd903/content/browser/renderer_host/media/in_process_video_capture_device_launcher.cc
[modify] https://crrev.com/5c7ba649624db0eebcdabcd6d0844c0c17ebd903/content/browser/renderer_host/media/in_process_video_capture_device_launcher.h
[modify] https://crrev.com/5c7ba649624db0eebcdabcd6d0844c0c17ebd903/content/browser/renderer_host/media/media_stream_manager.cc
[modify] https://crrev.com/5c7ba649624db0eebcdabcd6d0844c0c17ebd903/content/public/browser/desktop_media_id.cc
[modify] https://crrev.com/5c7ba649624db0eebcdabcd6d0844c0c17ebd903/content/public/browser/desktop_media_id.h
[modify] https://crrev.com/5c7ba649624db0eebcdabcd6d0844c0c17ebd903/media/capture/video/fake_video_capture_device.h
[modify] https://crrev.com/5c7ba649624db0eebcdabcd6d0844c0c17ebd903/media/capture/video/fake_video_capture_device_factory.cc
[modify] https://crrev.com/5c7ba649624db0eebcdabcd6d0844c0c17ebd903/media/capture/video/fake_video_capture_device_factory.h
[modify] https://crrev.com/5c7ba649624db0eebcdabcd6d0844c0c17ebd903/media/capture/video/fake_video_capture_device_unittest.cc

emircan: great to see progress here.

How do you envision testing? Ideally it would just work as today, see https://bugs.chromium.org/p/chromium/issues/detail?id=459532 for some history on the interactions between screensharing and the fake-ui flag (including a workaround). If you fixed that as a drive-by that would of course be great :-)

> How do you envision testing? Ideally it would just work as today, see https://bugs.chromium.org/p/chromium/issues/detail?id=459532 for some history on the interactions between screensharing and the fake-ui flag (including a workaround). If you fixed that as a drive-by that would of course be great :-)

It will work as CL description states:
- use-fake-ui-for-media-stream by itself will bypass picker and selection. Default one I picked right now is desktop capture. It doesn't know about the available sources. Works in content_shell. (I guess this is the case you were after in that bug.)
- auto-select-desktop-capture-source work similar to as above, but actually pops picker ui and doesn't work in content_shell.
- use-fake-device-for-media-stream doesn't really do anything by itself. I can technically work on adding fake device as an option to the actual Picker UI but I dont see its use in testing.
- use-fake-ui-for-media-stream and use-fake-device-for-media-stream bypasses the selection and picks fake device(famous pacman loop) by default. use-fake-device-for-media-stream=display-media-type={any,monitor,window,browser} changes how that fake device appears to the JS.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/72323ebd454e1b73b2e9b202c503e6653aff6acd

commit 72323ebd454e1b73b2e9b202c503e6653aff6acd
Author: Emircan Uysaler <emircan@chromium.org>
Date: Fri Aug 17 23:06:12 2018

Handle getDisplayMedia case in MediaStreamCaptureIndicator

This CL adds getDisplayMedia() calls going through MediaStreamCaptureIndicator
into the existing |desktop_stream_count_|.

Bug: 326740
Change-Id: I4c16e41c281d96bd9012b4bb66381d5c81d351ca
Reviewed-on: https://chromium-review.googlesource.com/1180097
Reviewed-by: Weiyong Yao <braveyao@chromium.org>
Reviewed-by: Sergey Ulanov <sergeyu@chromium.org>
Commit-Queue: Emircan Uysaler <emircan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#584228}
[modify] https://crrev.com/72323ebd454e1b73b2e9b202c503e6653aff6acd/chrome/browser/media/webrtc/media_stream_capture_indicator.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/666489e8a16e385d9dce282ace433fdbd7557c5c

commit 666489e8a16e385d9dce282ace433fdbd7557c5c
Author: Emircan Uysaler <emircan@chromium.org>
Date: Tue Aug 21 03:12:54 2018

Add histogram count for getDisplayMedia()

Bug: 326740
Change-Id: I08e30219e436c6be1216b6b94e9d7c5ed5b611d0
Reviewed-on: https://chromium-review.googlesource.com/1179253
Reviewed-by: Henrik Boström <hbos@chromium.org>
Reviewed-by: Christian Fremerey <chfremer@chromium.org>
Commit-Queue: Emircan Uysaler <emircan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#584622}
[modify] https://crrev.com/666489e8a16e385d9dce282ace433fdbd7557c5c/content/renderer/media/stream/user_media_client_impl.cc
[modify] https://crrev.com/666489e8a16e385d9dce282ace433fdbd7557c5c/content/renderer/media/webrtc/webrtc_uma_histograms_unittest.cc
[modify] https://crrev.com/666489e8a16e385d9dce282ace433fdbd7557c5c/third_party/blink/public/platform/web_rtc_api_name.h
[modify] https://crrev.com/666489e8a16e385d9dce282ace433fdbd7557c5c/tools/metrics/histograms/enums.xml

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/18e656a8712c7a1765b795de2ef84334f1449210

commit 18e656a8712c7a1765b795de2ef84334f1449210
Author: Emircan Uysaler <emircan@chromium.org>
Date: Wed Aug 22 17:03:05 2018

Enable video requests from getDisplayMedia()

This CL allows getDisplayMedia() calls where video is enabled to cross from
blink to content side. Additionally, it applies the constraints handling
mentioned in the spec(current state) and adds Layout tests.

Bug: 326740
Change-Id: I864f485595c63485cc70e519796072f928e22e4c
Reviewed-on: https://chromium-review.googlesource.com/1179310
Reviewed-by: Harald Alvestrand <hta@chromium.org>
Reviewed-by: Guido Urdaneta <guidou@chromium.org>
Commit-Queue: Emircan Uysaler <emircan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#585099}
[add] https://crrev.com/18e656a8712c7a1765b795de2ef84334f1449210/third_party/WebKit/LayoutTests/external/wpt/screen-capture/OWNERS
[add] https://crrev.com/18e656a8712c7a1765b795de2ef84334f1449210/third_party/WebKit/LayoutTests/external/wpt/screen-capture/getdisplaymedia.https-expected.txt
[add] https://crrev.com/18e656a8712c7a1765b795de2ef84334f1449210/third_party/WebKit/LayoutTests/external/wpt/screen-capture/getdisplaymedia.https.html
[delete] https://crrev.com/f27e8316289db3872d83ca8b1bf2aa3258848364/third_party/WebKit/LayoutTests/fast/mediastream/getdisplaymedia.html
[modify] https://crrev.com/18e656a8712c7a1765b795de2ef84334f1449210/third_party/blink/renderer/modules/mediastream/user_media_client.cc
[modify] https://crrev.com/18e656a8712c7a1765b795de2ef84334f1449210/third_party/blink/renderer/modules/mediastream/user_media_request.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/24e31432c12caf3d26cc9d87c9c6461d6682d509

commit 24e31432c12caf3d26cc9d87c9c6461d6682d509
Author: Emircan Uysaler <emircan@chromium.org>
Date: Fri Aug 31 21:04:02 2018

Add observable settings for getDisplayMedia()

This CL adds observable settings to MediaStreamTrack objects returned by
getDisplayMedia() calls. These constrainable properties are set before
the stream is returned based on user choice.

Information about these settings are stored in DisplayMediaInformation
struct. It is set in the low level device selection and then parsed by
UserMediaProcessor before passing it to blink.

Bug: 326740
Change-Id: I81d5f2eb24d2c1a37df0fbe2d34bc469fa575bf1
Reviewed-on: https://chromium-review.googlesource.com/1185875
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Guido Urdaneta <guidou@chromium.org>
Reviewed-by: Weiyong Yao <braveyao@chromium.org>
Commit-Queue: Emircan Uysaler <emircan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#588162}
[modify] https://crrev.com/24e31432c12caf3d26cc9d87c9c6461d6682d509/chrome/browser/media/webrtc/desktop_capture_devices_util.cc
[modify] https://crrev.com/24e31432c12caf3d26cc9d87c9c6461d6682d509/chrome/browser/media/webrtc/desktop_capture_devices_util.h
[modify] https://crrev.com/24e31432c12caf3d26cc9d87c9c6461d6682d509/chrome/browser/media/webrtc/display_media_access_handler_unittest.cc
[modify] https://crrev.com/24e31432c12caf3d26cc9d87c9c6461d6682d509/content/browser/renderer_host/media/media_stream_manager.cc
[modify] https://crrev.com/24e31432c12caf3d26cc9d87c9c6461d6682d509/content/browser/renderer_host/media/media_stream_manager_unittest.cc
[modify] https://crrev.com/24e31432c12caf3d26cc9d87c9c6461d6682d509/content/common/media/media_stream_param_traits.h
[modify] https://crrev.com/24e31432c12caf3d26cc9d87c9c6461d6682d509/content/public/common/media_stream_request.h
[modify] https://crrev.com/24e31432c12caf3d26cc9d87c9c6461d6682d509/content/renderer/media/stream/media_stream_constraints_util_video_device.cc
[modify] https://crrev.com/24e31432c12caf3d26cc9d87c9c6461d6682d509/content/renderer/media/stream/media_stream_constraints_util_video_device.h
[modify] https://crrev.com/24e31432c12caf3d26cc9d87c9c6461d6682d509/content/renderer/media/stream/media_stream_video_track.cc
[modify] https://crrev.com/24e31432c12caf3d26cc9d87c9c6461d6682d509/media/base/BUILD.gn
[add] https://crrev.com/24e31432c12caf3d26cc9d87c9c6461d6682d509/media/base/display_media_information.cc
[add] https://crrev.com/24e31432c12caf3d26cc9d87c9c6461d6682d509/media/base/display_media_information.h
[modify] https://crrev.com/24e31432c12caf3d26cc9d87c9c6461d6682d509/third_party/WebKit/LayoutTests/external/wpt/screen-capture/getdisplaymedia.https-expected.txt
[modify] https://crrev.com/24e31432c12caf3d26cc9d87c9c6461d6682d509/third_party/WebKit/LayoutTests/external/wpt/screen-capture/getdisplaymedia.https.html
[modify] https://crrev.com/24e31432c12caf3d26cc9d87c9c6461d6682d509/third_party/blink/public/platform/web_media_stream_track.h
[modify] https://crrev.com/24e31432c12caf3d26cc9d87c9c6461d6682d509/third_party/blink/renderer/modules/mediastream/media_stream_track.cc
[modify] https://crrev.com/24e31432c12caf3d26cc9d87c9c6461d6682d509/third_party/blink/renderer/modules/mediastream/media_track_settings.idl

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0e0cd9079b7460dd7cac9c712a6e684f5aec70dc

commit 0e0cd9079b7460dd7cac9c712a6e684f5aec70dc
Author: Emircan Uysaler <emircan@chromium.org>
Date: Wed Sep 05 01:30:44 2018

Add browsertest covering getDisplayMedia() cases

Bug: 326740
Change-Id: I9c75b405e4b5a8a216901df48b5cc41d39ba34fb
Reviewed-on: https://chromium-review.googlesource.com/1187650
Commit-Queue: Emircan Uysaler <emircan@chromium.org>
Reviewed-by: Sergey Ulanov <sergeyu@chromium.org>
Reviewed-by: Christian Fremerey <chfremer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#588730}
[add] https://crrev.com/0e0cd9079b7460dd7cac9c712a6e684f5aec70dc/chrome/browser/media/webrtc/webrtc_getdisplaymedia_browsertest.cc
[modify] https://crrev.com/0e0cd9079b7460dd7cac9c712a6e684f5aec70dc/chrome/test/BUILD.gn
[add] https://crrev.com/0e0cd9079b7460dd7cac9c712a6e684f5aec70dc/chrome/test/data/webrtc/webrtc_getdisplaymedia_test.html

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9276195f314bdc0ea578b534bf31754582721e99

commit 9276195f314bdc0ea578b534bf31754582721e99
Author: Emircan Uysaler <emircan@chromium.org>
Date: Sat Sep 22 23:25:20 2018

Use URL instead of title in request text

Bug: 326740
Change-Id: I6cbb658b6fed6bdc7bf48700f60d17a02176f65a
Reviewed-on: https://chromium-review.googlesource.com/1239513
Commit-Queue: Emircan Uysaler <emircan@chromium.org>
Reviewed-by: Weiyong Yao <braveyao@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593449}
[modify] https://crrev.com/9276195f314bdc0ea578b534bf31754582721e99/chrome/browser/media/webrtc/display_media_access_handler.cc

Is there any word on when the flag will be removed for this feature? Currently you have to set “Enable Experimental Web Platform Features“ to get getDisplayMedia in Chrome Beta (70). Will the flag be removed in time for 70 to go to stable?

[Empty comment from Monorail migration]

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ff3e1e268fd7ab71412fe3c939fc70c9a3185e4a

commit ff3e1e268fd7ab71412fe3c939fc70c9a3185e4a
Author: Emircan Uysaler <emircan@chromium.org>
Date: Wed Oct 17 19:36:16 2018

Filter mandatory constraints for getDisplayMedia()

Update to the spec suggests that we now enable certain constraints in
getDisplayMedia() call. This CL will allow them from higher level and update
wpt tests. Note that actual application of constraints will follow in the next
CLs.

Bug: 326740
Change-Id: I1f0b3c9b7a2feab7b17ee79c8c2420d9ced7fda8
Reviewed-on: https://chromium-review.googlesource.com/c/1284733
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Commit-Queue: Emircan Uysaler <emircan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#600519}
[modify] https://crrev.com/ff3e1e268fd7ab71412fe3c939fc70c9a3185e4a/third_party/WebKit/LayoutTests/external/wpt/screen-capture/getdisplaymedia.https-expected.txt
[modify] https://crrev.com/ff3e1e268fd7ab71412fe3c939fc70c9a3185e4a/third_party/WebKit/LayoutTests/external/wpt/screen-capture/getdisplaymedia.https.html
[modify] https://crrev.com/ff3e1e268fd7ab71412fe3c939fc70c9a3185e4a/third_party/blink/public/platform/web_media_constraints.h
[modify] https://crrev.com/ff3e1e268fd7ab71412fe3c939fc70c9a3185e4a/third_party/blink/renderer/modules/mediastream/user_media_request.cc
[modify] https://crrev.com/ff3e1e268fd7ab71412fe3c939fc70c9a3185e4a/third_party/blink/renderer/platform/exported/web_media_constraints.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/63b28a13cd523a035e47aac8f37b6cbb750005f7

commit 63b28a13cd523a035e47aac8f37b6cbb750005f7
Author: Emircan Uysaler <emircan@chromium.org>
Date: Thu Oct 25 15:03:22 2018

Add more tests covering constraints usage in getDisplayMedia()

Bug: 326740
Change-Id: I923fb55c07424573d2a2829f8c5ef22fc4e28466
Reviewed-on: https://chromium-review.googlesource.com/c/1292371
Reviewed-by: Guido Urdaneta <guidou@chromium.org>
Reviewed-by: Henrik Boström <hbos@chromium.org>
Commit-Queue: Emircan Uysaler <emircan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#602709}
[modify] https://crrev.com/63b28a13cd523a035e47aac8f37b6cbb750005f7/chrome/browser/media/webrtc/webrtc_getdisplaymedia_browsertest.cc
[modify] https://crrev.com/63b28a13cd523a035e47aac8f37b6cbb750005f7/chrome/test/data/webrtc/webrtc_getdisplaymedia_test.html
[modify] https://crrev.com/63b28a13cd523a035e47aac8f37b6cbb750005f7/third_party/WebKit/LayoutTests/external/wpt/screen-capture/getdisplaymedia.https-expected.txt
[modify] https://crrev.com/63b28a13cd523a035e47aac8f37b6cbb750005f7/third_party/WebKit/LayoutTests/external/wpt/screen-capture/getdisplaymedia.https.html

How to test the API?
Running Chrome 70 with '--enable-experimental-web-platform-features' switch, when I call navigator.getDisplayMedia() I get the following error:

"DOMException: User Media support is disabled"

As with all powerful features, you have to call it in a secure context (https or localhost).

#98 - can you improve the error message? I think it usually makes it clear that you need a secure context.
However, should it be exposed at all in insecure contexts?
Perhaps the specification should change to add [SecureContext] (I forget the exact name) to getDisplayMedia?

#98: Nope, I'm still getting the same error with both https and localhost.

mkhahani@ can you share your JS call?

[Comment Deleted]

Now it's working with Chrome 70.0.3538.77.
I was testing on Chromium 70.0.3515.0 with no luck!

I'm just wondering why the API doesn't support audio while it's bringing up exactly the same dialog as chrome.desktopCapture.chooseDesktopMedia() does and the latter supports audio?!

We are planning to support audio capture in Chrome. Audio part was vague in the spec and and other browsers weren't interested in supporting it, so we decided to roll with video support as the first step.

Thanks for the reply. The audio capture is definitely useful and I'm using this feature in my app via extension.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d0734458c5723e607313da871f71288203b50b1c

commit d0734458c5723e607313da871f71288203b50b1c
Author: Emircan Uysaler <emircan@chromium.org>
Date: Mon Nov 05 20:16:58 2018

Move getDisplayMedia to MediaDevices

Following https://github.com/w3c/mediacapture-screen-share/pull/86

Bug: 326740
Change-Id: Ifb65a33a7f998563640d9f508d26d91ecb16c32f
Reviewed-on: https://chromium-review.googlesource.com/c/1313188
Reviewed-by: Henrik Boström <hbos@chromium.org>
Reviewed-by: Philip Jägenstedt <foolip@chromium.org>
Reviewed-by: Harald Alvestrand <hta@chromium.org>
Commit-Queue: Emircan Uysaler <emircan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605436}
[modify] https://crrev.com/d0734458c5723e607313da871f71288203b50b1c/chrome/test/data/webrtc/webrtc_getdisplaymedia_test.html
[modify] https://crrev.com/d0734458c5723e607313da871f71288203b50b1c/third_party/WebKit/LayoutTests/external/wpt/interfaces/screen-capture.idl
[modify] https://crrev.com/d0734458c5723e607313da871f71288203b50b1c/third_party/WebKit/LayoutTests/external/wpt/screen-capture/getdisplaymedia.https-expected.txt
[modify] https://crrev.com/d0734458c5723e607313da871f71288203b50b1c/third_party/WebKit/LayoutTests/external/wpt/screen-capture/getdisplaymedia.https.html
[modify] https://crrev.com/d0734458c5723e607313da871f71288203b50b1c/third_party/WebKit/LayoutTests/external/wpt/screen-capture/idlharness.window.js
[modify] https://crrev.com/d0734458c5723e607313da871f71288203b50b1c/third_party/WebKit/LayoutTests/webexposed/global-interface-listing-expected.txt
[modify] https://crrev.com/d0734458c5723e607313da871f71288203b50b1c/third_party/blink/renderer/modules/mediastream/BUILD.gn
[modify] https://crrev.com/d0734458c5723e607313da871f71288203b50b1c/third_party/blink/renderer/modules/mediastream/media_devices.cc
[modify] https://crrev.com/d0734458c5723e607313da871f71288203b50b1c/third_party/blink/renderer/modules/mediastream/media_devices.h
[modify] https://crrev.com/d0734458c5723e607313da871f71288203b50b1c/third_party/blink/renderer/modules/mediastream/media_devices.idl
[delete] https://crrev.com/08d4fc12a3943194683934413d051551c5da7c4f/third_party/blink/renderer/modules/mediastream/navigator_display_media.cc
[delete] https://crrev.com/08d4fc12a3943194683934413d051551c5da7c4f/third_party/blink/renderer/modules/mediastream/navigator_display_media.h
[delete] https://crrev.com/08d4fc12a3943194683934413d051551c5da7c4f/third_party/blink/renderer/modules/mediastream/navigator_display_media.idl
[modify] https://crrev.com/d0734458c5723e607313da871f71288203b50b1c/third_party/blink/renderer/modules/modules_idl_files.gni

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9d6b90094f06a4aa14159f8a35b19e95f9887aec

commit 9d6b90094f06a4aa14159f8a35b19e95f9887aec
Author: Emircan Uysaler <emircan@chromium.org>
Date: Tue Nov 06 05:40:46 2018

Add use counter for getDisplayMedia

Bug: 326740
Change-Id: Iea381d99984249796fb0e11279174a553ea9ce8a
Reviewed-on: https://chromium-review.googlesource.com/c/1313328
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Dominick Ng <dominickn@chromium.org>
Reviewed-by: Guido Urdaneta <guidou@chromium.org>
Reviewed-by: Henrik Boström <hbos@chromium.org>
Commit-Queue: Emircan Uysaler <emircan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605602}
[modify] https://crrev.com/9d6b90094f06a4aa14159f8a35b19e95f9887aec/third_party/blink/public/platform/web_feature.mojom
[modify] https://crrev.com/9d6b90094f06a4aa14159f8a35b19e95f9887aec/third_party/blink/renderer/modules/mediastream/media_devices.idl
[modify] https://crrev.com/9d6b90094f06a4aa14159f8a35b19e95f9887aec/tools/metrics/histograms/enums.xml

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8de9d5f05d03904d1c9868c765b1afef18ee5b5c

commit 8de9d5f05d03904d1c9868c765b1afef18ee5b5c
Author: Emircan Uysaler <emircan@chromium.org>
Date: Mon Nov 12 18:01:31 2018

Enable GetDisplayMedia by default in blink

See https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/eKS6bOz9a_o
for Intent to Ship and lgtms.

Bug: 326740
Change-Id: I2d8cec26bae32281e50137dfd1616926b66e61a8
Reviewed-on: https://chromium-review.googlesource.com/c/1292439
Commit-Queue: Emircan Uysaler <emircan@chromium.org>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Cr-Commit-Position: refs/heads/master@{#607287}
[modify] https://crrev.com/8de9d5f05d03904d1c9868c765b1afef18ee5b5c/android_webview/tools/system_webview_shell/test/data/webexposed/global-interface-listing-expected.txt
[modify] https://crrev.com/8de9d5f05d03904d1c9868c765b1afef18ee5b5c/third_party/WebKit/LayoutTests/virtual/stable/webexposed/global-interface-listing-expected.txt
[modify] https://crrev.com/8de9d5f05d03904d1c9868c765b1afef18ee5b5c/third_party/blink/renderer/platform/runtime_enabled_features.json5

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2094eb4c38be91cc2790a05b85d8e60e433be270

commit 2094eb4c38be91cc2790a05b85d8e60e433be270
Author: Emircan Uysaler <emircan@chromium.org>
Date: Tue Nov 13 18:25:09 2018

Follow URL display guidelines in DisplayMediaAccessHandler

We should not use title in any of notification or request texts because it can
easily be injected. We should use URL instead and follow the guidelines to
simplify.

Bug: 326740
Change-Id: Ib9d6ea0c996883a206a2cb016c505b8280ad6cc9
Reviewed-on: https://chromium-review.googlesource.com/c/1324911
Reviewed-by: Christopher Thompson <cthomp@chromium.org>
Reviewed-by: Weiyong Yao <braveyao@chromium.org>
Commit-Queue: Emircan Uysaler <emircan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#607663}
[modify] https://crrev.com/2094eb4c38be91cc2790a05b85d8e60e433be270/chrome/browser/media/webrtc/display_media_access_handler.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b573fcc404ab3c3e2917a12b2c41e7ff6c202cf3

commit b573fcc404ab3c3e2917a12b2c41e7ff6c202cf3
Author: Emircan Uysaler <emircan@chromium.org>
Date: Wed Nov 14 18:55:23 2018

Change default selection in getDisplayMedia to cancel

To prevent permissions being accepted accidentally, permission prompts should
not be accepted as the default action. This CL changes default selection to
cancel button to reflect that.

Bug: 326740
Change-Id: I29d3e5c61c6a56546c7d9ada0824d3fccb91bc4f
Reviewed-on: https://chromium-review.googlesource.com/c/1334856
Reviewed-by: Christopher Thompson <cthomp@chromium.org>
Reviewed-by: Qiang Chen <qiangchen@chromium.org>
Commit-Queue: Emircan Uysaler <emircan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608064}
[modify] https://crrev.com/b573fcc404ab3c3e2917a12b2c41e7ff6c202cf3/chrome/browser/ui/views/desktop_capture/desktop_media_picker_views.cc
[modify] https://crrev.com/b573fcc404ab3c3e2917a12b2c41e7ff6c202cf3/chrome/browser/ui/views/desktop_capture/desktop_media_picker_views.h
[modify] https://crrev.com/b573fcc404ab3c3e2917a12b2c41e7ff6c202cf3/chrome/browser/ui/views/desktop_capture/desktop_media_picker_views_browsertest.cc

Please consider also the following related issue I posted a few months ago. It was labeled as TE-NeedsTriageHelp at that time but now I think it's a good time to be reviewed.

https://bugs.chromium.org/p/chromium/issues/detail?id=815100

Let me know if it needs more explanation.
Thanks.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0ec959f96db10622eee34b30579073a8b3b194a3

commit 0ec959f96db10622eee34b30579073a8b3b194a3
Author: Emircan Uysaler <emircan@chromium.org>
Date: Wed Nov 21 20:58:43 2018

Add kill switch for getDisplayMedia

getDisplayMedia() allows capturing user's display content. Before launching this
feature, we want to add a kill switch that can be set from server side in case
there exists some use case that causes security or privacy problems.

Bug: 326740
Change-Id: I34cf0cb412c599712fa10b0beb40b18404cf0440
Reviewed-on: https://chromium-review.googlesource.com/c/1313192
Commit-Queue: Emircan Uysaler <emircan@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Weiyong Yao <braveyao@chromium.org>
Reviewed-by: Philip Jägenstedt <foolip@chromium.org>
Reviewed-by: Guido Urdaneta <guidou@chromium.org>
Reviewed-by: Henrik Boström <hbos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#610208}
[modify] https://crrev.com/0ec959f96db10622eee34b30579073a8b3b194a3/chrome/browser/media/webrtc/media_capture_devices_dispatcher.cc
[modify] https://crrev.com/0ec959f96db10622eee34b30579073a8b3b194a3/content/child/runtime_features.cc
[modify] https://crrev.com/0ec959f96db10622eee34b30579073a8b3b194a3/third_party/blink/common/features.cc
[modify] https://crrev.com/0ec959f96db10622eee34b30579073a8b3b194a3/third_party/blink/public/common/features.h
[modify] https://crrev.com/0ec959f96db10622eee34b30579073a8b3b194a3/third_party/blink/public/platform/web_runtime_features.h
[modify] https://crrev.com/0ec959f96db10622eee34b30579073a8b3b194a3/third_party/blink/renderer/platform/exported/web_runtime_features.cc

Has getDisplayMedia() been moved to navigator.mediaDevices in chrome yet?

#114, yes it has, see #107.

And is up in the current version of chrome? I recently used getDisplayMedia() straight from navigator

#116, it is available after 72.0.3608.4.

[Comment Deleted]

What are the backwards compatibility/transition plans on getUserMedia()/webkitGetUserMedia() once getDisplayMedia() is released?

We are excited about getDisplayMedia() being release (particularly about getting rid of extensions) but we cannot transition to it until system audio capture is supported.

#119, we will add audio support and we have updated the spec accordingly. But right now we're prioritizing getting the first version of the API out in the same way is it's supported by Edge and Firefox.

#120 Thanks for the clarification, but the more specific question is whether Chromium/Chrome will keep supporting webkitGetUserMedia() (in particular system audio capture) until it's implemented in getDisplayMedia()

I assume you're referring to the extension API chooseDesktopMedia that then feeds into getUserMedia? Yes, that will be supported at least until audio is added to getDisplayMedia.

Hi guys,

will this also be supported on Android devices?

Thanks,
Luis

Sorry if this is a silly question, but I'm new to chromium and CEF. From the comments, it looks like the DesktopMediaPickerFactoryImpl would give the same selection dialog/etc that you'd see in chrome. Is that something that I'd be able to access or trigger from CEF or is this specific to chromium?

Thanks for any help,
Chris

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/69161eec8ef8e87cf1d196c3b4d6c8eb7869daf9

commit 69161eec8ef8e87cf1d196c3b4d6c8eb7869daf9
Author: Emircan Uysaler <emircan@chromium.org>
Date: Wed Jan 09 18:39:44 2019

Change default selection in getDisplayMedia to cancel for Mac

To prevent permissions being accepted accidentally, permission prompts should
not be accepted as the default action. This CL changes default selection to
cancel button to reflect that. Earlier CL affected Views, but Mac still uses
its own controller. This CL addresses that specifically.

Bug: 326740, 919456
Change-Id: I0ed7d9c61b3795af6b1ff91f801548d4b7bc1ed3
Reviewed-on: https://chromium-review.googlesource.com/c/1403394
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Emircan Uysaler <emircan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#621237}
[modify] https://crrev.com/69161eec8ef8e87cf1d196c3b4d6c8eb7869daf9/chrome/browser/ui/cocoa/media_picker/desktop_media_picker_controller.mm
[modify] https://crrev.com/69161eec8ef8e87cf1d196c3b4d6c8eb7869daf9/chrome/browser/ui/cocoa/media_picker/desktop_media_picker_controller_unittest.mm

As per https://crbug.com/chromium/326740#c109 this feature appears to be enabled by default in Canary, but the platform status (https://www.chromestatus.com/features/6744724455030784) does not indicate it as shipping. Is it on schedule for stable release?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e791f87078fc5309424cd816b891a3661a3bbf49

commit e791f87078fc5309424cd816b891a3661a3bbf49
Author: Emircan Uysaler <emircan@chromium.org>
Date: Fri Jan 11 16:13:03 2019

Change default selection in getDisplayMedia to cancel for Mac

To prevent permissions being accepted accidentally, permission prompts should
not be accepted as the default action. This CL changes default selection to
cancel button to reflect that. Earlier CL affected Views, but Mac still uses
its own controller. This CL addresses that specifically.

Bug: 326740, 919456
Change-Id: I0ed7d9c61b3795af6b1ff91f801548d4b7bc1ed3
Reviewed-on: https://chromium-review.googlesource.com/c/1403394
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Emircan Uysaler <emircan@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#621237}(cherry picked from commit 69161eec8ef8e87cf1d196c3b4d6c8eb7869daf9)
Reviewed-on: https://chromium-review.googlesource.com/c/1407033
Reviewed-by: Emircan Uysaler <emircan@chromium.org>
Cr-Commit-Position: refs/branch-heads/3626@{#640}
Cr-Branched-From: d897fb137fbaaa9355c0c93124cc048824eb1e65-refs/heads/master@{#612437}
[modify] https://crrev.com/e791f87078fc5309424cd816b891a3661a3bbf49/chrome/browser/ui/cocoa/media_picker/desktop_media_picker_controller.mm
[modify] https://crrev.com/e791f87078fc5309424cd816b891a3661a3bbf49/chrome/browser/ui/cocoa/media_picker/desktop_media_picker_controller_unittest.mm

The following revision refers to this bug:
https://chromium.googlesource.com/chromium/src.git/+/e791f87078fc5309424cd816b891a3661a3bbf49

Commit: e791f87078fc5309424cd816b891a3661a3bbf49
Author: emircan@chromium.org
Commiter: emircan@chromium.org
Date: 2019-01-11 16:13:03 +0000 UTC

Change default selection in getDisplayMedia to cancel for Mac

To prevent permissions being accepted accidentally, permission prompts should
not be accepted as the default action. This CL changes default selection to
cancel button to reflect that. Earlier CL affected Views, but Mac still uses
its own controller. This CL addresses that specifically.

Bug: 326740, 919456
Change-Id: I0ed7d9c61b3795af6b1ff91f801548d4b7bc1ed3
Reviewed-on: https://chromium-review.googlesource.com/c/1403394
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Emircan Uysaler <emircan@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#621237}(cherry picked from commit 69161eec8ef8e87cf1d196c3b4d6c8eb7869daf9)
Reviewed-on: https://chromium-review.googlesource.com/c/1407033
Reviewed-by: Emircan Uysaler <emircan@chromium.org>
Cr-Commit-Position: refs/branch-heads/3626@{#640}
Cr-Branched-From: d897fb137fbaaa9355c0c93124cc048824eb1e65-refs/heads/master@{#612437}

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

#66
> 2) does not allow restricting the display surfaces the same way chooseDesktopMedia does -- reordering was just shipped in M61 so there must be some use-case for that
> Reducing the initial scope to the equivalent of ['screen', 'window'] might be an option if that means you can ship soon enough.

Hello, I'm just to tell about use-case for restricting the display surfaces.

We develop an application for online proctoring (examus.info). We ask the user to share his display so that the proctor can prevent cheating during the exam. To allow proctors doing their job, user must share his entire screen, and not a separate application or a browser tab. (Though, more realistically, just one monitor.)

When the dialog is dismissed it throws "NotAllowedError:Permission denied" while it should throw "NotAllowedError:Permission dismissed" just like what mic/webcam do.

This issue was migrated from crbug.com/chromium/326740?no_tracker_redirect=1

[Monorail blocked-on: crbug.com/webrtc/1757]
[Monorail blocking: crbug.com/chromium/118551, crbug.com/chromium/850536, crbug.com/chromium/865060, crbug.com/chromium/896333]
[Monorail mergedwith: crbug.com/chromium/739465, crbug.com/chromium/754681, crbug.com/chromium/830832, crbug.com/webrtc/1757]
[Monorail components added to Component Tags custom field.]