+++ This bug was initially created as a clone of Bug #1609578 +++

STRs:

1. In a video meeting https://jsfiddle.net/jib1/q75yb8pf/ click the "Present" button to present a document to your audience
2. 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
3. Dismiss the prompt using the least restrictive negative option (Block)
4. 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 Now or 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

Set release status flags based on info from the regressing bug 1206232

:johannh, since you are the author of the regressor, bug 1206232, could you take a look?
For more information, please visit auto_nag documentation.

Set release status flags based on info from the regressing bug 1206232

Setting 102 and 103 to Won't Fix based on comment 0, not tracking as a regression

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)

?

Sounds reasonable and should be easy to implement.
We need the go from Paul.

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?

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?

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?

It's kind of a one liner. @jib, I will add you as a reviewer.

https://hg.mozilla.org/mozilla-central/rev/0ec825077cdb