70

Introduction

Mac OS X Lion has a full screen feature that allows use of a single application window in full screen, i.e. without window title bar and constantly visible menu bar, on its own virtual desktop.

There's a problem however. If you press Escape while in full screen, and the application does not consume the event, you leave full screen. If we dismiss accidental key presses, this leaves programs that react to keyUp, but neither of keyDown and keyPress.

It did take some time to determine the details in this question. Only @dpk figured it out in the last few comments to the question, the other comments and answers are mostly useless or just plain wrong.

Request

enter image description here

The behavior described above appears with the "dialogs" on the Stack Exchange sites. They can be dismissed by pressing Escape. Since they only react to keyUp, the key press itself is not consumed by the browser.

Please change, at least on OS X, the behavior of these dialog boxes: They should response to a different event. Alternatively, consume any Esc keyDown in browser on Mac OS X, just to keep use of Esc from closing the dialog, while the dialog is visible.

IMO, it makes sense for a web site UI to prevent a web browser's default action on keyDown/keyPress (whatever that action is) if the keyUp event on the web page is responded to. If limited to when such a dialog is visible, this shouldn't hurt any default functionality, especially since a repeated key press will perform the default action. But allowing the program to perform two unrelated actions when a key is pressed doesn't make any sense at all. So either remove the Escape functionality for dialog boxes, or also intercept the other events.

Early proof of concept

The following bookmarklet achieves the desired effect for the close dialog:

javascript:(function(){document.onkeydown=function(evt){if(evt.keyCode==27&&document.getElementById('close-question-popup').style.display!='none')return false;};})();

It'd be no sane one-liner if I'd include the flag popups, as their element IDs contain the related post's ID, and there is one for each answer.

Bug classification

Apparently, the proper way to handle this is preventDefault. It appears to be something that is expected on anyone doing event handling: Handle all events that are triggered when a particular key is pressed so no unexpected side effects (such as the one presented here) occur. Therefore retagging to a .

User script fix

Here's a user script (4 lines of boiler plate code from here) that will fix this behavior:

// ==UserScript==
// @name         SE Lion Full Screen Compatibility
// @namespace    http://meta.stackexchange.com/q/113212
// @description  Makes SE sites behave in Mac OS X Lion's full screen mode
// @include      http://stackoverflow.com/*
// @include      http://meta.stackoverflow.com/*
// @include      https://superuser.com/*
// @include      http://meta.superuser.com/*
// @include      http://serverfault.com/*
// @include      http://meta.serverfault.com/*
// @include      http://askubuntu.com/*
// @include      http://meta.askubuntu.com/*
// @include      http://answers.onstartups.com/*
// @include      http://meta.answers.onstartups.com/*
// @include      http://nothingtoinstall.com/*
// @include      http://meta.nothingtoinstall.com/*
// @include      http://seasonedadvice.com/*
// @include      http://meta.seasonedadvice.com/*
// @include      https://stackapps.com/*
// @include      http://*.stackexchange.com/*
// @exclude      http://chat.stackexchange.com/*
// @exclude      http://chat.*.stackexchange.com/*
// @exclude      http://api.*.stackexchange.com/*
// @exclude      http://data.stackexchange.com/*
// ==/UserScript==

function with_jquery(f) {
    var script = document.createElement("script");
    script.type = "text/javascript";
    script.textContent = "(" + f.toString() + ")(jQuery)";
    document.body.appendChild(script);
}

with_jquery(function ($) {
    $('body').keydown(function (e) {
        if (e.keyCode === 27) {
            if ($('#close-question-popup').is(":visible") || $("*[id*='flag-popup-']").is(":visible")) {
                e.preventDefault();
            }
        }
    });
});

It currently supports the following dialogs:

  • Close question dialog
  • Flag question and flag answer dialogs

Tested on Safari using NinjaKit only, but should be simple enough to work in other browsers. I'm not an experienced jQuery/user script programmer (as should be obvious), so feel free to fix bugs or suggest improvements. Please also provide the IDs of other dialogs that can be closed with Escape so they can be added to the script.

This post on Super User links to a few user script plugins, and contains another user script that will prevent Escape from leaving full screen mode in browsers on all sites.

 Radar issue

I submitted a bug report to Apple against Safari 5 on February 24. It is tracked as Bug ID# 10926183 (rdar://10926183). If you want to support this issue, please file bugs yourself and mention that they're duplicates of this issue. I don't think anything will come from this, since it's a bug resulting from carelessness by the web developers who implemented the event handling, but it's worth a try. In any case, this will only help with Safari. Consider submitting a similar issue to your favorite browser vendor.

Below is the description I submitted to Apple, Markdown formatted for MSO.

Safari leaves full screen mode in Lion even if some key events are handled

Summary:

Safari leaves OS X Lion full screen mode on web pages handling only the keyUp event for the Escape key, which is often used by web page authors to provide some kind of keyboard navigation.

Safari, as a web browser, is highly dependent on content and scripts provided by web pages. JavaScript can handle events like keyDown and keyUp, and many web sites use these to implement keyboard navigation. Unfortunately, leaving full screen mode only requires the keyDown event being unhandled.

Steps to Reproduce:

  1. Create a web page document with the following JavaScript code:
    <script type="text/javascript">document.onkeyup = function (evt) { if (evt.keyCode == 27) alert("keyUp"); e.preventDefault(); return false; }</script>
  2. Open that web page document
  3. Go into full screen mode
  4. Press Escape

Expected Results:

Safari does not leave full screen mode.

Actual Results:

Safari does leave full screen mode.

Regression:

-

Notes:

Full screen mode is not left when the web page responds to keyDown instead. Full screen mode is only left upon releasing the key, even though this functionality seems to be triggered from the keyDown event.


Safari, as a web browser, is highly dependent on content and scripts provided by web pages. JavaScript can handle events like keyDown and keyUp, and many web sites use this to implement keyboard navigation.

Many web sites implement non-character key handling by registering a keyUp event handler. Pressing Escape to invoke some web site functionality will therefore both invoke the functionality and leave full screen mode, since no keyUp event can be triggered without keyDown.

Given the provided script code, the web page author intended for no default browser functionality to be invoked when the user presses the Escape key. Safari should not leave full screen mode in this situation even though technically it's an issue with the web page script programming not prevent default functionality of all events invoked when a key is pressed.

10
  • 1
    Please do this! Commented Jan 23, 2012 at 20:34
  • 2
    s/Safari/Every Browser on Mac OS X/g
    – VxJasonxV
    Commented Feb 8, 2012 at 22:53
  • 1
    @VxJasonxV Their fullscreen behavior is equally broken? Commented Feb 8, 2012 at 22:58
  • 10
    It's relevant to Chrome too. Really any browser that has implemented Lion-style Full Screen. I use Chrome, so the point being that this applies to any compatible browser, not simply Safari.
    – VxJasonxV
    Commented Feb 8, 2012 at 23:58
  • 1
    You mean people actually use full screen mode?
    – Cody Gray
    Commented Mar 12, 2012 at 8:41
  • 1
    @CodyGray I do. Not so much for Safari, but Mail, Reeder, iTunes work rather well with it. Commented Mar 12, 2012 at 11:20
  • Given that your bug report is already partially public, you may want to consider adding the bug report to Open Radar.
    – icktoofay
    Commented Dec 28, 2013 at 4:56
  • Can't reproduce on Firefox, esc doesn't leave fullscreen mode at all. Commented Jan 16, 2014 at 4:43
  • 1
    @LoïcFaure-Lacroix Seems to be an unresolved issue in Firefox, see 675631 and 474070. In other words, while all other applications on OS X close fullscreen when pressing Esc, Firefox doesn't. Commented Jan 16, 2014 at 10:54
  • @DanielBeck I wish it was "by design" won't fix Commented Jan 16, 2014 at 11:41

1 Answer 1

3

I don't see this behavior for Chrome in OSX Awesome Cat, but I was able to reproduce the problem in Safari. I'll look into it.

Update: One of the reasons that this one hasn't been addressed in so long is because the most practical way to do it would be to do something global with the keyup/keydown/keypress events, which is pretty risky. It could potentially affect browser UI that we have no way to be aware of, and we could inadvertently shoot ourselves in the foot by doing something globally and then forgetting about it and then having a feature in another part of the app not act right.

I know this isn't the answer you wanted, but the right answer is for Apple to fix this in Safari. It's the only browser that still does this wrong. Every other mainstream browser uses ^⌘F to enter and leave fullscreen display, and fixed the problem you described by no longer using ESC. Safari already supports ^⌘F, so all they would need to do is follow the other browsers in not using ESC.

5
  • 1
    That took a while…
    – bjb568
    Commented Oct 4, 2014 at 1:31
  • 2
    Sorry about that. Sometimes things fall through the cracks, especially if they aren't responded to right away Commented Oct 4, 2014 at 1:34
  • So what's wrong with preventDefault? Also, since this was one of the top 10 voted bugs for years, it appears that voting on this site is a useless waste of time -- is that the case? Commented Feb 28, 2015 at 12:13
  • @DanielBeck if we (they) did that, it would be impossible to know or test for the breakage in other parts of the site it would cause. It's almost guaranteed to cause a regression somewhere, and this really isn't even our (their) bug. Commented Feb 28, 2015 at 18:18
  • 1
    @DanielBeck voting is definitely not a waste of time. Higher-voted bug reports get a much greater visibility. The reason that sometimes these higher-voted bugs don't get fixed is because they are insanely hard. There's a very high correlation between number of upvotes and difficulty. Commented Feb 28, 2015 at 18:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .