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

NEW
Unassigned

Status

()

Firefox
Device Permissions
2 years ago
2 years ago

People

(Reporter: Ovidiu, Unassigned)

Tracking

(Depends on: 1 bug)

Trunk
Points:
---

Firefox Tracking Flags

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

Details

(Whiteboard: [fxprivacy] )

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
Created attachment 8783482 [details]
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.
Whiteboard: [fxprivacy] [triage]
(Reporter)

Updated

2 years ago
status-firefox48: --- → unaffected
status-firefox49: --- → unaffected
status-firefox50: --- → unaffected
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.
Is this really a problem that didn't affect previous Firefox versions?
Flags: needinfo?(ovidiu.boca)
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.
(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.
Depends on: 1225156
Can UX weigh in on this? Thank you.
Flags: needinfo?(agrigas)
Whiteboard: [fxprivacy] [triage] → [fxprivacy]

Comment 6

2 years ago
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...
Flags: needinfo?(agrigas)
(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

2 years ago
(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.
(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.
This did not break because of bug 1225156.
No longer blocks: 1206233
(In reply to Panos Astithas [:past] from comment #10)
> This did not break because of bug 1225156.

Er, I meant bug 1206233.
See Also: → bug 1224453
(Reporter)

Comment 12

2 years ago
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.
Flags: needinfo?(ovidiu.boca)
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.
(Reporter)

Comment 14

2 years ago
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.
Duplicate of this bug: 1300064
(Reporter)

Updated

2 years ago
Blocks: 1206233
As said in comment 10 / comment 11, this isn't something bug 1206233 broke.
No longer blocks: 1206233
You need to log in before you can comment on or make changes to this bug.