I was actually fine with gating fullscreen on engagement, but I suppose a reasonable compromise is preventing the auto-hiding if the engagement score is too low. That certainly provides good cover to set the threshold at the high end.

I'm concerned about the interactive fullscreen website use case (gaming, remote access) having a button on screen that's from the browser UI when engagement is low. (And terrified of the encroachment of fully gating APIs on engagement --- that path leads to an unusable drive-by web experience).

+scheib who has consistently argued for removing interference in fullscreen.

Solutions I would be comfortable with:
- If engagement is low, keep the "Press Esc to exit fullscreen" prompt on-screen until dismissed; add an X button that dismisses the prompt (but does not exit FS). Worried that people will not click the X because they think it will exit FS, and that people will still leave the prompt up when giving a presentation.
- If engagement is low, actually prompt before entering fullscreen (unlike the old behaviour where we used to prompt *after* entering fullscreen).

Regardless, we should fix the fullscreen loop issue ( Issue 749243 ) and that should mitigate most of the attack surface. We may not need to be more aggressive against this.

FYI: Use of engagement as a blocker for fullscreen was discussed in  Issue 654140 .

+PM, +UX

background - full screen is being abused more now that there isn't a permission prompt.

mgiuca@ - I don't understand your concern here. In the low engagement case, the user just needs to dismiss the UI for escaping fullscreen. In the high-engagement case it can auto-dismiss.

#8 I originally thought Ben was proposing an "exit FS" button. It looks like the proposal is actually just to keep it on-screen but have an X button that exits fullscreen. That alleviates my concern, mostly.

However the two minor concerns I have are:
1. That people will not understand that the X is going to dismiss the prompt (they may assume it exits FS, and therefore keep it on screen always).
2. That people will just leave it up there anyway and not dismiss it, which was behaviour we saw in the old days and was one of the reasons we made it auto-dismiss.

But since it's only for low engagement, this isn't a big deal.

> 1. That people will not understand that the X is going to dismiss the prompt (they may assume it exits FS, and therefore keep it on screen always).

On the windows side I know we regularly get complaints that touch-only users cannot escape fullscreeen. So, there's already a compelling argument for an escape button on the fullscreen dialog. However, I'm trying not to bleed that outstanding issue into this crisis, because the bigger concern is the users currently at risk.


> 2. That people will just leave it up there anyway and not dismiss it, which was behaviour we saw in the old days and was one of the reasons we made it auto-dismiss.

I find this line of argument concerning. We know fullscreen is a big abuse target--in fact, this exact class of threat is why I required that the fullscreen dialog not auto-dismiss when it was shipped several years ago. So, I don't think it's helpful to argue the nuisance aspect when we're now contending with users facing serious harm over this new behavior.

I think it's great that we can now use the engagement score to reduce the number of people experiencing the nuisance case. But really, the priority here is to protect the population of users who are getting tricked into installing malware or otherwise putting themselves at risk.

Emily / Max, would be great to get your opinion and thoughts on this.

I think we should go with the proposal outlined in c#1. Good idea Ben :)

To summarize: for low engagement only, keep "esc to exit FS" instructions on-screen with an "x" button that dismisses the instructions. The X button should not impact the fullscreen-ness, just dismiss the prompt.

Re c#9.1, this is an interesting point generally -- we use X to mean both "cancel" and "exit". This might be a larger UI issue we need to address. (Cancel and don't do anything vs. cancel and kill something). It might be worth doing some research (not blocking this change) to see if that's indeed the case. Touch only users is an independent issue. Do we have a bug open for that already?
Re c#9.2, this concern also isn't too concerning to me given the abuse + availability of engagement score thresholding.

OK, I think we need to get a mock and an asset for the X. Attached is a screenshot of the current UI on Linux (should look the same everywhere).

Deleted: Screenshot from 2017-08-08 11:11:31.png 37.8 KB

	Screenshot from 2017-08-08 11:11:31.png 37.8 KB View Download

+1 on the intent and rough design of this change, pointer lock adds complications.


In earlier redesign we roughly distilled use cases as all falling under 'distraction free & immersive application use' with notable application types of:
- watching video [presumed to completely dominate the uses]
- games
- presentations
- remote desktop or virtual machines
- full screen tools, e.g. code editors.

Video was most sensitive to the initial design that persisted a bubble until the user pressed "Accept". Auto-dismissing if the site has engagement solves that -- so long as it still works when in an iframe.

All other cases will follow through the same logic.

At the LON Fizz offsite at the beginning of engagement a wide group came to the consensus that engagement shouldn't be used to restrict features. This change passes that test -- the feature still works, just with extra notice.


Regarding UI/UX, I'd suggest a button with word such as "Dismiss".



Pointer Lock
What good is a dismiss button when you are unable to click it?

If combined with FS this will be particularly annoying.  Following the 'engagement should not disable features' principal makes this solution difficult.  So, I'd bias strongly towards keeping pointer lock working (vs just denying it due to low engagement).

Option "prompt":
The initial bubble did not provide pointer lock until 'Accept' was pressed.  To 'Accept' you must know what you're accepting. ('Dismiss' works, because you're just dismissing the message.)  This implies that if FS and PL are requested on low engagement we'd show like the old bubble's, "[origin] wants to control your pointer. Esc to exit. [Accept] [Dismiss]" (I forget the exact string we used).

Option "persist":
On low engagement we could simply persist the Esc instructions indefinitely.  This will make some sites hard to use if the message obscures content on the page.  I don't like this option much, but it's easiest to implement.

Re #14, do you mean pointer lock will prevent the drop down notification from being clicked? Is that necessary? That is, can we just make it clickable even if pointer lock is on?

#15: No, nothing can be made clickable when pointer lock is on. Pointer lock doesn't just hide the mouse cursor or prevent it from leaving the area; it completely removes the concept of a mouse cursor and delivers raw mouse events to the app (for example, so you can implement a first-person shooter where the mouse controls aiming). There's no way to make a button clickable while the user is in a first-person shooter interface.

Ah, OK. Bummer.

Given that I think Option "persist" is OK for pointer lock + FS. We can make it go away once the engagement threshold is reached (i.e. if the user keeps interacting with the page for a while it will disappear).

ping Max - let me know if you'd like to meet about this.