Able to reproduce the issue on win8.1 chrome version 53.0.2757.0

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Not sure this has anything to do with the video element itself, this happens with any fullscreen content (e.g. launch fullscreen on https://davidwalsh.name/demo/fullscreen.php and then press Esc).

Print preview (via ConstrainedWebDialogDelegateViewViews) currently consumes the key down event for the escape key. It closes when this event is received. So a webpage watching for the key down event on the escape key will not receive the event, but if the webpage is watching for the key up event on the escape key, it will receive the event since it occurs after the print preview dialog has closed. These full screen examples appear to be watching for the key up event and exiting full screen when it is received.

Not sure how (or if) we want to fix this. It is possible to change the behavior so that the dialog consumes the key down event but remains open to consume the key up event. It will then close when the key up event is received. This prevents the background page from receiving any events from an Escape key press that occurs when Print Preview is active. However, this also means if a user holds down the escape key the print preview will remain visible and active until they release the key (currently, it will disappear as soon as escape is pressed down).

It is also possible to make the dialog "disappear" without actually closing it when the key down event occurs. This can be achieved by making it transparent and too small to interact with. The dialog will actually close, invisibly to the user, when the key up event occurs, so that it can consume that event also. This will also prevent the underlying page from getting the key event and makes the dialog appear to close at the right time, but it also eliminates the current animation for the preview closing. The dialog will appear to simply vanish.

Note that this same behavior can be observed with the Cast UI since it uses the same ConstrainedWebDialogDelegateViewViews class.

cc-ing hwi@ and jawag@ for input on what the best option would be.

In my opinion, neither of the options you are proposing seem too bad -- I would be surprised if many users "hold" the escape key for any significant period of time (do we know?) and I also have a hard time believing many users would notice a significant difference if we skipped the preview-close animation. It's pretty subtle.

From a UX consistency standpoint I can see how one could argue against both of these options, but I think either would be an improvement over the current experience, with a slight preference for the latter option (skipping the close animation). Hwi, what do you think?

+skonig, is the Cast team currently thinking about this? Any plans?

Based on  bug 728276 , this is now irrelevant, as opening the print preview dialog should cause the page to exit full screen.