Denying a video/audio stream with 'remember this decision' checked should stop existing streams for the same domain

NEW
Unassigned

Status

()

P3
normal
2 years ago
a year ago

People

(Reporter: Ovidiu, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(firefox48 unaffected, firefox49 unaffected, firefox50 unaffected, firefox51 affected)

Details

(Whiteboard: [fxprivacy] )

(Reporter)

Description

2 years ago
[Affected versions]:

FF Nightly 51.0a1


[Affected platforms]:


Tested on Mac OS X 10.10


[Steps to reproduce]:

1. Open https://people.mozilla.org/~fqueze2/webrtc/ in two tabs.
2. In tab 1 click Audio and Video and select "Share selected devices". 
3. In tab 2 click Audio and Video and select never share.


[Expected result]:

 Tab1 the video and audio are working, and control center shows audio and video icons unblocked. 

[Actual result]:

Tab1 the video and audio are working, but control center shows both blocked.
Whiteboard: [fxprivacy] [triage]
(Reporter)

Updated

2 years ago
status-firefox48: --- → unaffected
status-firefox49: --- → unaffected
status-firefox50: --- → unaffected
(In reply to ovidiu boca[:Ovidiu] from comment #0)

> [Expected result]:
> 
>  Tab1 the video and audio are working, and control center shows audio and
> video icons unblocked. 
> 
> [Actual result]:
> 
> Tab1 the video and audio are working, but control center shows both blocked.

Well, they are actually blocked, in that any future request will be blocked without even showing a prompt.

I guess one possible fix here would be to stop streams in the first tab when "never share" is selected in the second tab. That seems potentially surprising though.
Another one we need UX for.
Flags: needinfo?(agrigas)
Whiteboard: [fxprivacy] [triage] → [fxprivacy]

Comment 3

2 years ago
(In reply to Florian Quèze [:florian] [:flo] (PTO until August 29th) from comment #1)
> (In reply to ovidiu boca[:Ovidiu] from comment #0)
> 
> > [Expected result]:
> > 
> >  Tab1 the video and audio are working, and control center shows audio and
> > video icons unblocked. 
> > 
> > [Actual result]:
> > 
> > Tab1 the video and audio are working, but control center shows both blocked.
> 
> Well, they are actually blocked, in that any future request will be blocked
> without even showing a prompt.
> 
> I guess one possible fix here would be to stop streams in the first tab when
> "never share" is selected in the second tab. That seems potentially
> surprising though.

Can we show a special dialogue that says there is already a video stream open and have a switch to tab option if the user is asked the permissions prompt. We shouldn't show them the allow/block actions if they've already made the decision for that domain in another tab...
Flags: needinfo?(agrigas)
(In reply to agrigas from comment #3)
> (In reply to Florian Quèze [:florian] [:flo] (PTO until August 29th) from
> comment #1)
> > (In reply to ovidiu boca[:Ovidiu] from comment #0)

> > I guess one possible fix here would be to stop streams in the first tab when
> > "never share" is selected in the second tab. That seems potentially
> > surprising though.
> 
> Can we show a special dialogue that says there is already a video stream
> open and have a switch to tab option if the user is asked the permissions
> prompt.

I guess we could, but this seems to be more work than this edge case is worth.

> We shouldn't show them the allow/block actions if they've already
> made the decision for that domain in another tab...

If they already made the decision and clicked "remember" we don't prompt them again. But when granting access to the camera or microphone only once, we should reprompt the next time the website wants to use the device (even if it's from the same tab). One of the reasons why we need to reprompt is that the prompt is also used to let the user select which device will be used.

Comment 5

2 years ago
(In reply to Florian Quèze [:florian] [:flo] from comment #4)
> (In reply to agrigas from comment #3)
> > (In reply to Florian Quèze [:florian] [:flo] (PTO until August 29th) from
> > comment #1)
> > > (In reply to ovidiu boca[:Ovidiu] from comment #0)
> 
> > > I guess one possible fix here would be to stop streams in the first tab when
> > > "never share" is selected in the second tab. That seems potentially
> > > surprising though.
> > 
> > Can we show a special dialogue that says there is already a video stream
> > open and have a switch to tab option if the user is asked the permissions
> > prompt.
> 
> I guess we could, but this seems to be more work than this edge case is
> worth.
> 
> > We shouldn't show them the allow/block actions if they've already
> > made the decision for that domain in another tab...
> 
> If they already made the decision and clicked "remember" we don't prompt
> them again. But when granting access to the camera or microphone only once,
> we should reprompt the next time the website wants to use the device (even
> if it's from the same tab). One of the reasons why we need to reprompt is
> that the prompt is also used to let the user select which device will be
> used.

If they make different decisions in each tab then, can we not respect them and show the expected - allowed in one and blocked in another?
If users make difference decisions in each tab but don't check the "Remember this decision" checkbox, we respect them and there's no problem.

The problem is when the user decides to temporarily allow in the first tab, and then permanently block in the second tab. After the user has persistently blocked in the second tab, whenever we show the control center for that domain, we show "blocked", except the stream initially allowed in the first tab is still active, which is confusing.

When users revoke permissions we also stop active streams, but blocking permanently in another tab isn't exactly the same as the "stop sharing" action.

Comment 7

2 years ago
(In reply to Florian Quèze [:florian] [:flo] from comment #6)
> If users make difference decisions in each tab but don't check the "Remember
> this decision" checkbox, we respect them and there's no problem.
> 
> The problem is when the user decides to temporarily allow in the first tab,
> and then permanently block in the second tab. After the user has
> persistently blocked in the second tab, whenever we show the control center
> for that domain, we show "blocked", except the stream initially allowed in
> the first tab is still active, which is confusing.
> 
> When users revoke permissions we also stop active streams, but blocking
> permanently in another tab isn't exactly the same as the "stop sharing"
> action.

OK, so two ideas - we keep as is and just terminate the other stream since clicking the checkbox is a very explicit action and I don't think users would do it accedentally.

Second, we could disable the check box and show text saying you have an open video session in another tab. Please close that tab in order to make changes...?
Since this is not a regression (Firefox 48 behaves in the exact same way) I'm marking this as P3.
Priority: -- → P3
(In reply to agrigas from comment #7)

> OK, so two ideas - we keep as is and just terminate the other stream since
> clicking the checkbox is a very explicit action and I don't think users
> would do it accedentally.

I like that this doesn't involve any visible UI change, I'm rephrasing the bug summary to match this suggestion.

> Second, we could disable the check box and show text saying you have an open
> video session in another tab. Please close that tab in order to make
> changes...?

I'm a bit reluctant to add more UI and more strings to handle such a rare edge case. Also, if the user allows temporarily in a first tab, there's no reason to prevent the user from allowing permanently in a second tab making the same request.
Summary: Device status propagates from one tab to another → Denying a video/audio stream with 'remember this decision' checked should stop existing streams for the same domain
See Also: → bug 1308213
You need to log in before you can comment on or make changes to this bug.