Javascript navigator.mediaDevices.getUserMedia moves source to front

Question

I'm using this code but when it gets the source it always moves that window to the front which is kind of annoying, but I don't see any options in this code that make it move to the front so not sure how to prevent it.

It moves the source to the front, in front of my app and puts the focus on that window rather than my app, so every time I get the source I have to click back on my app again.

  navigator.mediaDevices.getUserMedia({
    audio: false,
    video: {
      mandatory: {
        chromeMediaSource: 'desktop',
        chromeMediaSourceId: desktop_id,
        minWidth: 2480,
        maxWidth: 2480,
        minHeight: 1440,
        maxHeight: 1440
      }
    }
  }).then(gotStream).catch(getUserMediaError);

EDIT: To avoid any confusion, this is the code from the Desktop Capturer app here https://github.com/hokein/electron-sample-apps/tree/master/desktop-capture

@Hermes It's this: https://github.com/hokein/electron-sample-apps/tree/master/desktop-capture — Hasen, May 19 '19 at 07:46
This is done by browsers to try to be helpful. Usually when people want to present or share something e.g. in a web conference call, focusing the chosen window and pushing it to front is exactly what users want and expect. What's your use-case where this isn't desired? — jib, May 19 '19 at 21:41
@jib Like in my question, it puts the image I'm capturing in focus and takes the focus off of my app so I have to reselect my app again. Why isn't that a valid use? What you say makes sense and seems like it might be useful sometimes but hardly essential, I think it should be disabled by default with an option to enable. Once I have captured the source I can see what has been captured in my app anyway...so really doesn't seem very useful. — Hasen, May 23 '19 at 11:30
You may very well have a valid use case, but when [filing an issue](https://github.com/w3c/mediacapture-screen-share/issues/new) it helps to have a compelling story with an example of an application that does something undeniably useful. You mention your app having a preview area, but not why, for instance. I struggle to picture the app or understand its purpose and why it works like this. You mention it being an electron app, so maybe this is a per-platform implementation decision, or maybe not and we need a new JS control surface, for instance. Context helps. — jib, May 23 '19 at 18:59
@jib I think if anyone opened the link to the code I provided everything would be very clear. There's an animation of the app in use on the github page. All the context is right there. — Hasen, May 24 '19 at 05:32

score 2 · Answer 1 · edited May 23 '19 at 13:11

2

This is done by browsers to try to be helpful. Usually when people want to present or share something e.g. in a web conference call, focusing the chosen window and pushing it to front is exactly what users want and expect.

The behavior is not a requirement in the spec, but both Chrome and newer versions of Firefox do this (and maybe other browsers as well).

Older versions of Firefox didn't do this, and it was confusing: you'd select a window and then it would appear as if nothing happened. This is because web conference sites typically don't show a self-view of what's being shared, since the expectation is typically that you'll be interacting with the window you're sharing directly, instead of staring at a thumbnail of it.

If you have a use-case where pushing the window to front is undesirable, consider filing an issue on the spec, explaining your use-case.

edited May 23 '19 at 13:11

Hasen

7,909
17
53
106

answered May 19 '19 at 21:57

jib

34,243
11
80
138

It's a privacy feature too. It helps users know which window is listening to or looking at them. – O. Jones May 23 '19 at 11:19
My code is not incorrect, it's the code from here https://github.com/hokein/electron-sample-apps/tree/master/desktop-capture It's an electron app so is the built in Chromium browser. The window being captured is a an image opened from my desktop in Apple preview. So it's not part of any browser window that is being focused. No windows is being selected per se, it's being captured. In this case focusing it would be counterproductive since it's the app that requires focus to use the captured source. – Hasen May 23 '19 at 11:33
Actually that code doesn't work at all anyway, it returns errors `Unknown constraint named width rejected` and `Unknown constraint named height rejected`. Looks like his code is correct after all. – Hasen May 23 '19 at 11:55
@Hasen you're right, thanks. I didn't see the `electron` tag, and confused this with the web method `getDisplayMedia`. Thanks for removing that part. – jib May 23 '19 at 16:49
@jib To make it clearer I also edited my original question to add the link to the Desktop Capturer app where the code comes from which also shows the app in action with an animation. It's all much clearer if that page is viewed. – Hasen May 24 '19 at 05:34
@Hasen A functionality demonstration app is not a sufficient use case. – jib May 24 '19 at 17:31
@jib Well I don't have a web use. If use in apps is not enough then I don't know...? – Hasen May 25 '19 at 03:37
@Hasen What is your app used for? – jib May 25 '19 at 03:55
@jib It's for personal use only so if it has to prove it's adding so much to the community for this bug to be fixed then I guess there's no chance of it being fixed for this case. – Hasen May 25 '19 at 04:37

Javascript navigator.mediaDevices.getUserMedia moves source to front

1 Answers1