1297041 - After you block the camera there is no way to unblock it from the iframes.

Status: RESOLVED FIXED

(Firefox :: Site Permissions, defect)

Description

[ovidiu boca[:Ovidiu]]

Attachment: Iframe.html

[Affected versions]:

FF Nightly 51.0a1


[Affected platforms]:


Tested on Mac OS X 10.10


[Steps to reproduce]:


1. Open the attached test case in Firefox  (Iframe.html)
2. In frame 1 click on Video and select "Never Share"
3. In frame 2 click on Video



[Expected result]:

 The camera is blocked and in control center a notification appears. 


[Actual result]:

The camera is blocked but no notification appears in control center. No way to unblock it from the iframes.

Comment 1

[Florian Quèze [:florian]]

This seems broken, but I'm not sure what the right behavior would be here. Showing the blocked camera icon in the location bar would be wrong, as the main page could still request device access. And dropping requests silently without showing any UI doesn't seem OK either.

Comment 2

[Florian Quèze [:florian]]

Is this really a problem that didn't affect previous Firefox versions?

Comment 3

[Johann Hofmann [:johannh]]

I'm not sure either, maybe we need a small new UX concept for that, e.g. showing the frame hostname below the permission row or something.

Comment 4

[Florian Quèze [:florian]]

(In reply to Johann Hofmann [:johannh] from comment #3)
> I'm not sure either, maybe we need a small new UX concept for that, e.g.
> showing the frame hostname below the permission row or something.

Within the control center panel we should show frame-specific permissions. See bug 1225156.

The part I'm really unsure about is how we can show a hint that opening the control center would make sense for this page.

Comment 5

[Erin Lancaster [:elan]]

Can UX weigh in on this? Thank you.

Comment 6

[Ash Grigas]

Can someone record a screen grab/gif so I can see the interaction? I can't open the test file and can think about how we can aid discovery better if I can see the problem better illustrated...

Comment 7

[Florian Quèze [:florian]]

(In reply to agrigas from comment #6)
> I can't open the test file

Why can't you open it? It's not a file you need to download, you just need to load:
https://bug1297041.bmoattachments.org/attachment.cgi?id=8783482
in a tab with a current Nightly and then follow the steps from the bug description.

Comment 8

[Ash Grigas]

(In reply to Florian Quèze [:florian] [:flo] from comment #7)
> (In reply to agrigas from comment #6)
> > I can't open the test file
> 
> Why can't you open it? It's not a file you need to download, you just need
> to load:
> https://bug1297041.bmoattachments.org/attachment.cgi?id=8783482
> in a tab with a current Nightly and then follow the steps from the bug
> description.

When I test this I don't get a permission prompt when I click Video in the first frame - I get an error. 

If the user selects Allow or Don't Allow on the main domain and we think its a security issue to apply that decision to the subframe, we should ask again on the subframe and then show the blocked icon if the user blocked it on the subframe.

Comment 9

[Panos Astithas (he/him) [:past] (please ni?)]

(In reply to ovidiu boca[:Ovidiu] from comment #0)
> [Expected result]:
> 
>  The camera is blocked and in control center a notification appears. 

Why do you say that this is the expected result? In 48 I see that the iframe's getUserMedia call returns an error and there is no way to allow the camera at all. No indicator appears in the identity panel or the control center, not even in the permissions section of the page info dialog about this.

> [Actual result]:
> 
> The camera is blocked but no notification appears in control center. No way
> to unblock it from the iframes.

This is true, but I would consider this as an improvement from the previous state. There is no indication of the approved or rejected permission (bug 1225156), but at least the prompt works. Unless the WebRTC spec says otherwise of course (e.g. calls from iframes are never allowed) in which case the discussion above for a better indicator is somewhat moot.

Comment 10

[Panos Astithas (he/him) [:past] (please ni?)]

This did not break because of bug 1225156.

Comment 11

[Panos Astithas (he/him) [:past] (please ni?)]

(In reply to Panos Astithas [:past] from comment #10)
> This did not break because of bug 1225156.

Er, I meant bug 1206233.

Comment 12

[ovidiu boca[:Ovidiu]]

Sorry for delay but I was out of the office. 

(In reply to Florian Quèze [:florian] [:flo] from comment #2)
> Is this really a problem that didn't affect previous Firefox versions?
The behaviour is the same for both FF48 and FF 51. 


  Panos, regarding the blocked camera, users shall encounter situations in which they will block the camera with "always block". The user will have the same site open in a new tab/window and it is expected to be notified that camera is always blocked, even the action to block it was operated under other tab/window. While I agree that my test case is a bit of an edge case, I believe the behaviour for the permissions should be intuitive for the user and in this case the user will expect to be notified what blocks the camera.

Comment 13

[Panos Astithas (he/him) [:past] (please ni?)]

Ovidiu I am not arguing that this is not a confusing behavior; I am trying to clarify whether this is a regression or not. If, like me, you don't see a permission indicator in 48, then this is just a bug to fix.

Comment 14

[ovidiu boca[:Ovidiu]]

From my point of view I don't see any regression from 48. The behaviour is the same like yours, I don't see  any permission indicator in 48. This is just another bug to fix.

Comment 16

[Florian Quèze [:florian]]

As said in comment 10 / comment 11, this isn't something bug 1206233 broke.

Comment 17

[Paul Zühlcke [:pbz]]

I can no longer reproduce the issue. It was resolved by implementing permissions policy.