Presenters who aren't ready shouldn't have to "Block" future permissions to back out of screen picker
Categories
(Firefox :: Site Permissions, defect, P3)
Tracking
()
People
(Reporter: jib, Assigned: h.sofie.p)
References
(Regression)
Details
(Whiteboard: [no-nag])
Attachments
(1 file)
+++ This bug was initially created as a clone of Bug #1609578 +++
STRs:
- In a video meeting https://jsfiddle.net/jib1/q75yb8pf/ click the "Present" button to present a document to your audience
- Say you can't find the document you wanted to present, or you're not ready to present right now after all for whatever reason
- Dismiss the prompt using the least restrictive negative option (
Block) - At a later point in the meeting, try clicking the "Present" button again
Expected result:
- The least restrictive option shown in step 3 should be
Not Nowor something similarly benign that merely dismisses the prompt. - Step 4 should work like step 1.
Actual result:
- The least restrictive option shown in step 3 is
Block. - Step 4 doesn't work, and the presenter is hosed (prevented from presenting) until they either locate the permission drop-down in the URL bar and revoke the "Temporarily Blocked ✖" permission, or (more likely) drop and rejoin the call by refreshing the page.
Parity
Other browsers are more lenient:
- Safari will block permission only after the user has dismissed the prompt 3 times
- Chrome appears to allow an unlimited number of attempts
| Reporter | ||
Updated•3 years ago
|
Comment 1•3 years ago
|
||
Set release status flags based on info from the regressing bug 1206232
Comment 2•3 years ago
|
||
:johannh, since you are the author of the regressor, bug 1206232, could you take a look?
For more information, please visit auto_nag documentation.
Updated•3 years ago
|
Comment 3•3 years ago
|
||
Set release status flags based on info from the regressing bug 1206232
| Reporter | ||
Updated•3 years ago
|
Comment 4•3 years ago
|
||
Setting 102 and 103 to Won't Fix based on comment 0, not tracking as a regression
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
| Reporter | ||
Comment 5•3 years ago
|
||
With bug 1609578 as precedent, can we reuse the same language here?
To keep it simple (no logic, 3-strikes or anything fancy), and since our UX already gives the user choices of negative responses today:
- "Block ▼" (default)
- "Always block" (in dropdown)
Would it work to do:
- "Now Now ▼" (default)
- "Block" (first in dropdown)
- "Always block" (second in dropdown)
?
| Assignee | ||
Comment 6•3 years ago
|
||
Sounds reasonable and should be easy to implement.
We need the go from Paul.
Comment 7•3 years ago
|
||
Agreed, it doesn't seem very hard to do. However I'm concerned about the user experience. We're making the choices more complex and it's not really clear what the difference is between "Not now" and "block" when only looking at these labels.
What if instead we extend the conditions we added in bug 1609578 for "camera" and "microphone" to also cover "screen". Then we would be changing the action to "not now" and keep "always block" as a dropdown option. What do you think?
| Reporter | ||
Comment 8•3 years ago
|
||
If you're saying: let's drop the "Block" option in favor of "Now Now ▼" and "Always block" then I am in favor.
But can't we just do that? What "conditions" from bug 1609578 would we need to extend?
Comment 9•3 years ago
|
||
I think it should be tweaking this condition to include "screen", right Hannah? Along with updating the code for the labels for specifically the "screen" doorhanger. Any other concerns?
https://searchfox.org/mozilla-central/rev/4e695325c5cfc6a37f271b98672f9c03252b1f6f/browser/actors/WebRTCParent.jsm#701-702
Currently this is a backlog bug, should we consider doing this sooner?
| Assignee | ||
Comment 10•3 years ago
|
||
It's kind of a one liner. @jib, I will add you as a reviewer.
| Assignee | ||
Comment 11•3 years ago
|
||
Updated•3 years ago
|
Comment 12•3 years ago
|
||
Comment 13•3 years ago
|
||
| bugherder | ||
Updated•3 years ago
|
Description
•