This thread https://groups.google.com/a/chromium.org/d/topic/blink-dev/wlRDnLbyVlk/discussion might be relevant to your interests too.

Rob, do you think this can live entirely in the browser (and thus could be cross-platform between Win and CrOS)? Currently CrOS users also have no UI to allow them to escape non-immersive FS with touch.

With the simple escape, this can likely live in views.

If we want to go for the full top-bar experience, then that will be more complicated.

Changing bug to distinguish application-fullscreen and browser-fullscreen. application-fullscreen happens in an app (like youtube) when a user taps the fullscreen button. Browser fullscreen happens when the user hits F11 or chooses the fullscreen icon from the menu.

This bug covers escaping application-fullscreen. I'll open a new bug for browser-fullscreen. (They both will probably have the same visual appearance, but escaping app-fullscreen will also inform the app of the change.)

This issue affects windows and chrome touch or mouse-only interfaces.

See also  issue 710991  for browser-fullscreen.

See  Issue 594868  for an extensive existing discussion on this topic.

That bug was marked "fixed" because we provided a context menu, but it sounds like you are trying to add more discoverable / non-overridable UI.

Note: It is important to be clear about what problem we are trying to solve here. Specifically, let's separate malicious sites (designed deliberately to trap users without providing a way out) versus normal sites (that aren't trying to trap the user, just want to provide a good experience).

A lot of the argument I'm seeing for a more aggressive UI to exit using the mouse is along the lines of "while you can exit using the context menu, sites can block that, and then the user is at the mercy of the site to provide mouse exit controls." So this is specifically designing around sites that BOTH a) block the context menu, AND b) provide no other mouse control to exit fullscreen.

Malicious sites: Unfortunately, if you are trying to protect against sites that DELIBERATELY engage in the above behaviour, it is a losing battle, because they also have the mouse lock API. A malicious site that wants to trap keyboard-less users in full screen can just use both fullscreen and mouse lock, and then defeat any UI that's predicated on the user moving the mouse cursor to certain parts of the screen. If you want to fight against this use case, you need a story for pointer lock as well.

Normal sites: Sites that happen to do both (a) and (b). Before we change the browser UI to tackle these sites, I think we should find out how widespread it is. I think almost all legitimate sites do provide an exit button (particularly, video players). If this is a problem, perhaps a solution is developer engagement ("make sure you provide a way to exit fullscreen with the mouse") rather than adding new intrusive UI to Chrome.

Agree with most of #9. 

This issue only arises if the user intentionally fullscreens an app, and that app chooses not to provide an escape mechanism that the user can access. Most sites provide a visible button, or allow the default longpress.

Some sites/apps might choose to only support exit through the ESC key. In that case an otherwise well-intentioned site would unintentionally lock keyboard-less users.

Perhaps we could enable this only devices that lack a keyboard? (Do we know if there is no keyboard?)

I think given that many of us were not aware of the context menu escape mechanism since a lot of sites choose to override the context menu handler, we need another escape mechanism.

The current proposal is provide a touch and by extension, mouse, friendly way to expose a Chrome control that allows the user to exit fullscreen through a mechanism that sites commonly do not override.

Mouse+pointer lock is interesting, and it's a separate issue in that should mouse lock be permitted on machines without a keyboard?

Sync'ed up with yuweih, and we both agree that only one dev needs to work on this (he's working on something similar with regards to Esc-lock). He's graciously agreed to pick up this part of the UI as well since it's very similar.

Why was this marked fixed? Was any UI work done?

As I understand it, we have two tracking issues:

-  Issue 594868  addressed the fact that it's literally impossible to escape without a keyboard, by adding a context menu item (fixed in 2016).
- This issue (per #11) addresses the fact that the context menu is still not very discoverable and also can be blocked by the developer. Exploring a more intuitive UI. I don't think anything has changed on that front.

 Issue 594868  is still getting comments which I'd like to direct to here. If this was actually fixed without my knowledge, please mention the CLs that fixed it and re-close. Thanks.

(Note: This doesn't just affect Windows any more; there are Chrome OS tablets which suffer the same issue.)

If I visit Youtube and go full-screen (that's "application fullscreen", right?), the video player does override the context menu, presenting its own menu instead.  However, when I long-press the touchscreen to activate this, I do also get a round "X" button that slides down from the top of the screen, just like if I go into browser fullscreen and open the "real" context menu.  I don't have an example of a website that totally disables context menus (is that even still possible without a special permission prompt? and if so, *why*?) to test if the "X" button still appears on long-press in that case.

 Issue 758456 

Just go to http://permission.site/, click the fullscreen button, and enter this on the console:

  document.oncontextmenu = () => false

The X button should still reveal when you long-press the screen.