Closed Bug 1127353 Opened 9 years ago Closed 7 years ago

There's no straightforward way to bring back the device sharing doorhanger after choosing to never share

Categories

(Firefox :: Site Permissions, defect)

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1206252

People

(Reporter: avaida, Unassigned)

Details

Reproducible on:
- Nightly 38.0a1 (2015-01-29)
- Aurora 37.0a2 (2015-01-29)
- Beta 36.0b4 ()
- Release 35.0.1 (20150122214805)

Affected platform(s):
- Windows 7 32 bit
- Windows 8.1 64 bit
- Ubuntu 14.04 LTS 32 bit
- Mac OS X 10.9.5

Steps to reproduce:
1. Launch Firefox.
2. From about:config, make sure that:
 a. getusermedia.screensharing.enabled is set to true
 b. getusermedia.screensharing.allowed_domains contains people.mozilla.org
3. Restart Firefox to apply the pref changes.
4. Access the following URL: https://people.mozilla.org/~fqueze2/webrtc/.
5. Click the "Audio" button.
6. From the "Share Selected Device" doorhanger, choose "Never Share".

Expected result:
The doorhanger remains in the Location Bar, as a simple indicator near the site identity panel. Clicking the indicator would bring up the doorhanger again in case the user changes his mind about sharing a device.

Actual result:
The only way to bring back the doorhanger is to clear the Site Preferences remembered by the browser for this website.

Additional notes:
- This issue is not a regression.
(In reply to Andrei Vaida, QA [:avaida] from comment #0)

> 2. From about:config, make sure that:
>  a. getusermedia.screensharing.enabled is set to true
>  b. getusermedia.screensharing.allowed_domains contains people.mozilla.org
> 3. Restart Firefox to apply the pref changes.

Step 2 isn't needed as you are not going to use screensharing. And even when enabling screensharing, I don't think 3 (restarting) is needed.

> 4. Access the following URL: https://people.mozilla.org/~fqueze2/webrtc/.
> 5. Click the "Audio" button.
> 6. From the "Share Selected Device" doorhanger, choose "Never Share".

> Expected result:
> The doorhanger remains in the Location Bar, as a simple indicator near the
> site identity panel. Clicking the indicator would bring up the doorhanger
> again in case the user changes his mind about sharing a device.

Philipp, I seem to remember (but couldn't find a bug) we agreed that showing the gray notification icon without opening the doorhanger would be better than just denying the request immediately when we have saved the "never share" persistent permission.
1. Is this something you still want us to do?
2. Do we need to change the wording of the "Never Share" label, if it's now becoming a "never bother me again" feature instead of an instant rejection of the request?
Flags: needinfo?(philipp)
Andrei, you mentioned in email this is only a problem with e10s. I'm not sure reading this that that's clear. If it is e10s related, can you put the e10s-tracking ? flag on the bug? Thanks!
Flags: needinfo?(andrei.vaida)
(In reply to Liz Henry :lizzard from comment #2)
> Andrei, you mentioned in email this is only a problem with e10s. I'm not
> sure reading this that that's clear. If it is e10s related, can you put the
> e10s-tracking ? flag on the bug? Thanks!

This issue is actually reproducible *with and without e10s*, so it isn't related strictly to it. I did failed to mention that in this report, sorry for the confusion.
Flags: needinfo?(andrei.vaida)
(In reply to Florian Quèze [:florian] [:flo] from comment #1)
> Philipp, I seem to remember (but couldn't find a bug) we agreed that showing
> the gray notification icon without opening the doorhanger would be better
> than just denying the request immediately when we have saved the "never
> share" persistent permission.
> 1. Is this something you still want us to do?
> 2. Do we need to change the wording of the "Never Share" label, if it's now
> becoming a "never bother me again" feature instead of an instant rejection
> of the request?

Yes, I think that's still the best way to deal with this issue. IMO we don't need to change the string, since there's still nothing shared and to the user, there is no difference between rejecting the request and leaving it in limbo.
Flags: needinfo?(philipp)
We fixed this in bug 1206252.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.