Should pending getDisplayMedia() calls reject on sleep and/or screen-lock?

[eladalon1983]

Assume:

const promise = navigator.mediaDevices.getDisplayMedia();

Should we perhaps reject the promise if either of the following happens?

1. Screen locked.
2. Device put to sleep.

It seems counter-productive to allow a user gesture to essentially still have an effect several hours later. Imagine especially the following scenario: The user delivers a gesture, waits 1 second, then closes the lid and runs off somewhere. Somewhere in between the gesture and the device going to sleep, the app called gDM and the UA displayed the prompt. Is it really reasonable for the prompt to still be up there next morning?

[bradisbell]

Is it really reasonable for the prompt to still be up there next morning?

Yes, why not? The user decided to do something, but then paused their work and came back to it later. Why should the application do something special here?

[youennf]

This is user agent and/or OS territory.
I think the spec allows both leaving the prompt or denying after some time, which seems good.

[eladalon1983]

Yes, why not? The user decided to do something, but then paused their work and came back to it later. Why should the application do something special here? [Emphasis mine - Elad]

I think the UA should do something special here, not the application.

Rationale to reject:

• A user closing a laptop lead with an outstanding prompt to start X, might expect their action to implicitly reject X.
• Some operating systems (macOS) have recently introduced screen-sharing experiences that some users find non-trivial to exit (I observed a very tech-savvy and competent colleague fail to realize that the esc key would cancel picking). Seeing such a prompt a day late might be very confusing for such users.

This is user agent and/or OS territory.

If all browsers happen to be aligned in their view of what should happen, it'd help compatibility to codify our agreement.

I think the spec allows both leaving the prompt or denying after some time, which seems good.

Could you please help me locate which part does that?

[eladalon1983]

I think the spec allows both leaving the prompt or denying after some time, which seems good.

Could you please help me locate which part does that?

@guidou has suggested this step might say as much:

Optionally, e.g., based on a previously-established user preference, for security reasons, or due to platform limitations, jump to the step labeled Permission Failure below.

Great. My reading here is indeed that "Optionally, e.g." means "for any reason, and here is an non-exhaustive list of potential reasons." But it could stand to be clarified. See PR #288 for that.

[eladalon1983]

The area of the spec referenced in #288 deals with heuristic rejection prior to the prompt. We should probably also explicitly call out that user agents MAY reject while the prompt is pending in the section immediately following it, which deals with "prompt the user to choose."

[youennf]

We could add a note stating that "prompt the user to choose" may timeout or deny after some time.
Maybe it should be codified in the permission spec directly.

[eladalon1983]

It's a bit of a bigger decision to add that into the Permissions spec. I'd opt for a localized change first. Wdyt?

[youennf]

I filed the above issue on permission spec. If we cannot get a quick fix there, proceeding with a local fix makes sense to me.

[bradisbell]

I think the UA should do something special here, not the application.

The user often doesn't know or care about the difference. They tell their computer to do a thing. They expect the computer to do the thing they told it to do. Permission prompts are already a source of friction. ("I told it to use my webcam, why is it now asking me if I'll allow it to use my webcam?") With your proposal, there will be additional friction. ("I started setting up for the meeting at my desk. Now I closed my laptop, carried it to the conference room, and it says that I rejected permission? I did no such thing...")

Please consider the way users see these things in the total presentation to them. The layers aren't always apparent to the users.

Rationale to reject:

• A user closing a laptop lead with an outstanding prompt to start X, might expect their action to implicitly reject X.

I can't think of any other action the user would expect the laptop to give up on just because the user closed the laptop. Users close the screen. They open it later and expect to see what was there before, just like a book. They don't need to know or care about the hundreds of things that happen with all the various levels of power states to keep their data and apps ready-to-go.

The laptop doesn't say, "you closed me, so I guess you don't need this Word document anymore." It doesn't say, "I guess the calculator you opened and didn't type anything into is no longer needed." It makes no assumptions at all.

Without some insurmountable technical reason, or an well-established well-known user story backed by some at-least minimal UX research, I don't think we should make assumptions about what the user wants or doesn't want. Let's leave the prompt and let the user decide.

[eladalon1983]

"I started setting up for the meeting at my desk. Now I closed my laptop, carried it to the conference room, and it says that I rejected permission? I did no such thing..."

I don't think it's a common user journey to click on some [screen-share] button in the Web app, close the lid, carry the laptop over to another room, then open the lid and expect to answer the screen-share dialog then. In fact, I expect most Web applications will also end up disconnecting from the meeting when you try that.

Further, if you already interact with the dialog to stop the capture, closing the lid will stop the capture (on Chrome). I think dismissing the dialog in the same case will be more expected (for those browsers that stop capture when you put the machine to sleep).

Users close the screen. They open it later and expect to see what was there before, just like a book.

Books don't have dangerous side effects (unless one lives on Discworld). Before we execute a dangerous action on behalf of the user, we double-check the user's true intention through an intentionally-frictive prompt. Whatever tests we run to ensure we execute the user's true wishes, I believe these tests should be executed together, and never a day or two apart.

The laptop doesn't say

Would having a dedicated error help the applications communicate to the user what went wrong? (It doesn't seem necessary to me, but if it helps others, I'm glad to support it.)

I don't think we should make assumptions about what the user wants or doesn't want.

Not making the proposed change is itself an assumption-driven choice.

[marcoscaceres]

So yeah, some prompts are fine to leave indefinitely, but maybe others not... I've sent a PR based on the situation in the OP:
w3c/permissions#432

Please take a look if that's good enough.

[jan-ivar]

Closed by w3c/permissions#432.