Intent to Implement and Ship: JavaScript dialogs exit HTML5 fullscreen

[Avi Drissman]

Contact emails

primary: a...@chromium.org

secondary: mgi...@chromium.org, mea...@chromium.org

Spec

https://fullscreen.spec.whatwg.org/

Summary

If a page shows a JavaScript dialog while it is in fullscreen (the HTML5 kind), it is exited from fullscreen.

Motivation

Fullscreen is a dual-edged sword. Because it allows a web page to take over the screen, it is immersive. Unfortunately, its immersiveness has the danger of being disorienting, because all the usual user-interface items (taskbar, menu bar, window titlebars) are removed.

JavaScript dialogs are also powerful. They block the user from interacting with the web page until the user responds to it. There is an escape hatch, however; the user can switch to a different tab or close the tab if a page is being abusive with its use of dialogs.

JavaScript dialogs and fullscreen do not mix well. The primary issue is that if a page enters fullscreen, it removes the dialog escape hatch of the user being able to switch to a different tab or close the tab. In addition, the appearance of the dialog can interfere with the user from being able to see the critical "press [esc] to leave fullscreen" bubble that might be the user's only indication that they have entered fullscreen.

Right now dialogs and the fullscreen bubble interfere because they are located at the same place on the screen. However, even if they were changed to not be located at the same place, having two different items appear on the screen at once is bad. One will be missed, because humans simply cannot pay attention to two things at once, and because the "press [esc] to leave fullscreen" bubble is security-critical, we cannot afford to have it be lost.

Because of this reasoning, the security UI team has decided that if a page shows a JavaScript dialog while it is in fullscreen, that the page should be exited from fullscreen. This ensures that JavaScript dialogs cannot be used as a weapon to distract users from security-critical UI.

Two notes:

1. This would not affect a page's ability to show a dialog while in user-initiated fullscreen. In that case, the user knows they're in fullscreen and our concerns do not hold.

2. This is being actively abused in the wild.

Interoperability and Compatibility Risk

It is possible that a page is using both fullscreen and dialogs. It's unlikely, though, because the point of fullscreen is to be immersive, and the point of dialogs is to not be immersive but shock the user into action.

The fullscreen spec (https://fullscreen.spec.whatwg.org/) does not have any provision for a user agent being allowed to unilaterally force an element to exit fullscreen. This clearly is an oversight. We already allow the user to force an element to exit fullscreen by pressing the escape key, and we advertise this fact; surely the intent of the spec cannot be that the page has a non-overridable ability to be fullscreened.

Edge: No signals

Firefox: No signals

Safari: No signals

Web developers: No signals

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

This will be implemented on desktop platforms.

 

OWP launch tracking bug

http://crbug.com/728276

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5669548871122944

Requesting approval to ship?

Yes.

[Jochen Eisinger]

I changed window.open() exiting fullscreen a long time ago, and I feel like doing the same for dialogs is in line with this.

Can you clarify whether print() will also exit fullscreen?

I assume you'll fully exit fullscreen before changing the stacking order for the dialog, right?

Anyways, lgtm1 to ship. I'll let Philip comment whether/how the fullscreen spec should be changed here

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACWgwAYaBdYy12OChde_uMDbzU%2B9Jns8u6g5g2QgKxDjeSaYAQ%40mail.gmail.com.

[Avi Drissman]

On Wed, May 31, 2017 at 2:54 PM, Jochen Eisinger <joc...@chromium.org> wrote:

Can you clarify whether print() will also exit fullscreen?

That wasn't my intention with this Intent, but if you want to approve that as well, I will implement that one too. (As Mr JavaScript Dialogs, my primary focus is on them, sometimes missing other dialogs.)

 

I assume you'll fully exit fullscreen before changing the stacking order for the dialog, right?

Correct: the order would be 1. fully exit fullscreen, 2. show the dialog with associated window/tab activation.

Avi

[Jochen Eisinger]

I'd totally approve the same behavior for print() as well.

btw, the code for window.open() is in ChromeClientImpl::CreateWindow

I think https://codereview.chromium.org/2177203002 should work for Flash, but I was too lazy to write a test to be able to land this... 

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACWgwAY1J%3DHcTTMv1CLSBpVmAZcx9yDdi9STVCczQv%2B4yFiCfA%40mail.gmail.com.

[Matt Giuca]

The argument that "One will be missed, because humans simply cannot pay attention to two things at once, and because the "press [esc] to leave fullscreen" bubble is security-critical, we cannot afford to have it be lost." and "This ensures that JavaScript dialogs cannot be used as a weapon to distract users from security-critical UI." isn't really viable. You could just as easily distract the user by showing an HTML dialog in your page at the same time as entering fullscreen.

That said, the other arguments are sound: the risk of showing an alert over the fullscreen notification is there, as well as the lack of a browser tab to close as a way of getting out of alert loops.

LGTM2. (For what it's worth... not sure if mine counts.)

Could we get the spec updated? It must be possible for the browser to exit a page out of fullscreen for whatever reason. For example if another tab is focused (which can happen autonomously if an alert is fired from another page), we will today exit full screen. I think the spec should allow the user agent to exit fullscreen at any time.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALjhuien6iuu%2BtiHwwQnJRV4Aw2FsBR_o2v%2BTSaWgGHhsvprOw%40mail.gmail.com.

[Avi Drissman]

On Thu, Jun 1, 2017 at 12:53 AM, Matt Giuca <mgi...@chromium.org> wrote:

LGTM2. (For what it's worth... not sure if mine counts.)

As this is an Intent, I'm looking for API_OWNER approvals. As you were part of the discussion deciding to go this route, I'd hope you were in agreement :)

 

Could we get the spec updated? It must be possible for the browser to exit a page out of fullscreen for whatever reason. For example if another tab is focused (which can happen autonomously if an alert is fired from another page), we will today exit full screen. I think the spec should allow the user agent to exit fullscreen at any time.

I can file a spec bug if that helps. I've filed against https://github.com/whatwg/html; would it be https://github.com/whatwg/fullscreen ?

Avi

 

[Matt Giuca]

On Thu, 1 Jun 2017 at 15:15 Avi Drissman <a...@google.com> wrote:

On Thu, Jun 1, 2017 at 12:53 AM, Matt Giuca <mgi...@chromium.org> wrote:

LGTM2. (For what it's worth... not sure if mine counts.)

As this is an Intent, I'm looking for API_OWNER approvals. As you were part of the discussion deciding to go this route, I'd hope you were in agreement :)

Right, I wasn't sure if there was a set of people who needed to approve. ;)

 

 

Could we get the spec updated? It must be possible for the browser to exit a page out of fullscreen for whatever reason. For example if another tab is focused (which can happen autonomously if an alert is fired from another page), we will today exit full screen. I think the spec should allow the user agent to exit fullscreen at any time.

I can file a spec bug if that helps. I've filed against https://github.com/whatwg/html; would it be https://github.com/whatwg/fullscreen ?

Yeah I think it should be filed against the fullscreen spec.

 

Avi

 

[PhistucK]

On Thu, Jun 1, 2017 at 7:53 AM, Matt Giuca <mgi...@chromium.org> wrote:

the risk of showing an alert over the fullscreen notification is there

I do not think this is a sound argument. This is a user interface problem (the notification can simply show up on top of the alert, or whatever), not a security risk.​

​

On Wed, May 31, 2017 at 9:38 PM, 'Avi Drissman' via blink-dev <blin...@chromium.org> wrote:

There is an escape hatch, however; the user can switch to a different tab or close the tab if a page is being abusive with its use of dialogs.

In that sense, the same escape hatch exists in full screen mode as well.

The user cannot switch to a different tab or close the tab while an alert() is showing in non-full-screen mode. They can close the alert box (or tick that check box and then close it) and only then they can switch to another tab. That is my observation on Windows.

I am not sure this feature (or deprecation or whatever) is really needed, but along the ride of discouraging those kinds of dialogs, it is a nice step. I do not see a real benefit other than the discouragement.

☆PhistucK

[Matt Giuca]

On Thu, 1 Jun 2017 at 15:42 PhistucK <phis...@gmail.com> wrote:

On Thu, Jun 1, 2017 at 7:53 AM, Matt Giuca <mgi...@chromium.org> wrote:

the risk of showing an alert over the fullscreen notification is there

I do not think this is a sound argument. This is a user interface problem (the notification can simply show up on top of the alert, or whatever), not a security risk.​

I was going to add (but didn't) that while we could consider this a simple UI bug and fix around it, it's hard (this bug has been open for nearly 2 years now), and much easier to do what Avi is suggesting. The Views system just doesn't support explicit ordering (dialogs overlay in the order they were presented). We looked into it multiple times and found that it would require deep changes to the Views system.

It's not "ideal" to intervene with a spec rather than fix UI bugs, but a) it's significantly less work, b) there are other reasons to do it as Avi has outlined, and c) only a very weak reading of the spec says we can't do this --- it doesn't explicitly forbid or allow us to break out of fullscreen whenever we want.

​

On Wed, May 31, 2017 at 9:38 PM, 'Avi Drissman' via blink-dev <blin...@chromium.org> wrote:

There is an escape hatch, however; the user can switch to a different tab or close the tab if a page is being abusive with its use of dialogs.

In that sense, the same escape hatch exists in full screen mode as well.

The user cannot switch to a different tab or close the tab while an alert() is showing in non-full-screen mode. They can close the alert box (or tick that check box and then close it) and only then they can switch to another tab. That is my observation on Windows.

The problem is that malicious sites can spawn a continuous stream of alerts, thus if the user closes the alert another one pops up.

Avi recently changed it so you can close the tab while an alert is open, making the most effective way to deal with an alert-bomb site to simply close the tab using the X, which can only be done out of fullscreen.

[PhistucK]

On Thu, Jun 1, 2017 at 9:32 AM, Matt Giuca <mgi...@chromium.org> wrote:

The problem is that malicious sites can spawn a continuous stream of alerts, thus if the user closes the alert another one pops up.

There is a check box that prevents this continuous stream.

Nice - closing the tab is also working on Windows! :) That should have been done years ago. :(

☆PhistucK

[Philip Jägenstedt]

On Wed, May 31, 2017 at 8:39 PM 'Avi Drissman' via blink-dev <blin...@chromium.org> wrote:

Contact emails

primary: a...@chromium.org

secondary: mgi...@chromium.org, mea...@chromium.org

Spec

https://fullscreen.spec.whatwg.org/

Summary

If a page shows a JavaScript dialog while it is in fullscreen (the HTML5 kind), it is exited from fullscreen.

Motivation

Fullscreen is a dual-edged sword. Because it allows a web page to take over the screen, it is immersive. Unfortunately, its immersiveness has the danger of being disorienting, because all the usual user-interface items (taskbar, menu bar, window titlebars) are removed.

JavaScript dialogs are also powerful. They block the user from interacting with the web page until the user responds to it. There is an escape hatch, however; the user can switch to a different tab or close the tab if a page is being abusive with its use of dialogs.

JavaScript dialogs and fullscreen do not mix well. The primary issue is that if a page enters fullscreen, it removes the dialog escape hatch of the user being able to switch to a different tab or close the tab. In addition, the appearance of the dialog can interfere with the user from being able to see the critical "press [esc] to leave fullscreen" bubble that might be the user's only indication that they have entered fullscreen.

Right now dialogs and the fullscreen bubble interfere because they are located at the same place on the screen. However, even if they were changed to not be located at the same place, having two different items appear on the screen at once is bad. One will be missed, because humans simply cannot pay attention to two things at once, and because the "press [esc] to leave fullscreen" bubble is security-critical, we cannot afford to have it be lost.

Because of this reasoning, the security UI team has decided that if a page shows a JavaScript dialog while it is in fullscreen, that the page should be exited from fullscreen. This ensures that JavaScript dialogs cannot be used as a weapon to distract users from security-critical UI.

Two notes:

1. This would not affect a page's ability to show a dialog while in user-initiated fullscreen. In that case, the user knows they're in fullscreen and our concerns do not hold.

2. This is being actively abused in the wild.

This all make sense to me. In addition, please also make sure to test what happens when alert() is called right after the requestFullscreen() call, while the change is pending but hasn't happened yet. A race which circumvents the protection is easy to imagine.

Also, does this include the print dialog?

 

Interoperability and Compatibility Risk

It is possible that a page is using both fullscreen and dialogs. It's unlikely, though, because the point of fullscreen is to be immersive, and the point of dialogs is to not be immersive but shock the user into action.

The fullscreen spec (https://fullscreen.spec.whatwg.org/) does not have any provision for a user agent being allowed to unilaterally force an element to exit fullscreen. This clearly is an oversight. We already allow the user to force an element to exit fullscreen by pressing the escape key, and we advertise this fact; surely the intent of the spec cannot be that the page has a non-overridable ability to be fullscreened.

This is covered in https://fullscreen.spec.whatwg.org/#ui by "If the end user instructs the user agent to end a fullscreen session"

Spec-wise, I think one could go one of two ways:

1. A "about to show modal dialog" extension point in https://html.spec.whatwg.org/multipage/webappapis.html#user-prompts that the fullscreen spec uses to cancel whatever it was doing.
   
2. Something more handwavy in https://fullscreen.spec.whatwg.org/#ui giving the UA a license to exit whenever it thinks it's in the best interest of the user.

Only with option 1 could one write web-platform-tests for it, and that'd be nice. However, I imagine this has to be implemented in the browser process, in which case the exit condition couldn't have anything to do with the state in the renderer, and what the fullscreen spec could talk about.

Do either of these paths make sense? Or another?

Edge: No signals

Firefox: No signals

Safari: No signals

Web developers: No signals

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

This will be implemented on desktop platforms.

 

OWP launch tracking bug

http://crbug.com/728276

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5669548871122944

Requesting approval to ship?

Yes.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACWgwAYaBdYy12OChde_uMDbzU%2B9Jns8u6g5g2QgKxDjeSaYAQ%40mail.gmail.com.

[Avi Drissman]

On Thu, Jun 1, 2017 at 2:50 AM, PhistucK <phis...@gmail.com> wrote:

There is a check box that prevents this continuous stream.

Not any more. That check box was there to allow users to get out of the situation where a page was bombarding them with alerts. That was always a cat-and-mouse game with abusive sites, and was removed with auto-dismissing dialogs because now the way out is to close the abusive site. 

[PhistucK]

Huh. Cool.

I wonder whether the user realizes that, though, given that the user experienced a lock up in those scenarios up until now. Perhaps, like me (and I follow the development of Chrome, but I think user-interface change this was not announced), they assume the lock up still exists.

☆PhistucK

[Avi Drissman]

We actually have statistics here that show that there is a decent uptake in users who close the tab and switch away.

Re this Intent I am working on a response.

[Avi Drissman]

On Thu, Jun 1, 2017 at 8:13 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

Also, does this include the print dialog?

Actually, despite what I said above, yes. Now that everyone is asking, let's include the print dialog in this.

2. Something more handwavy in https://fullscreen.spec.whatwg.org/#ui giving the UA a license to exit whenever it thinks it's in the best interest of the user.

I prefer this option, because it also covers our existing behavior where we drop fullscreen when the page opens a popup. (See Jochen's email higher on the thread, where he makes a case for this Intent corresponding to our existing behavior re popups.)

I opened a spec bug: https://github.com/whatwg/fullscreen/issues/93

Avi

[Rick Byers]

LGTM2

Normally we block on spec changes, but if we're thinking of this as an extension of what we already do for window.open (and urgent from a security perspective) then I'm OK handling the spec bug in parallel.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACWgwAbXGdruxLcon2bvMLrjTuexu4t_H5Y4dE7ReAvnd4RApA%40mail.gmail.com.

[Philip Jägenstedt]

LGTM3 to proceed with implementation and spec in parallel. If I could see the Chromium change, it'll be easier to know how to massage the spec into allowing just enough leeway, and at what "layer."

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_-1f%3D1F2sdosUgCNxYMN%2BdcHCc0EXECF%2BEmEmoaYo6%3DA%40mail.gmail.com.