1. #1
    Ext User
    Join Date
    May 2007
    Posts
    31
    Vote Rating
    0
    kato is on a distinguished road

      0  

    Default [2.0] Modal dialogs can be bypassed

    [2.0] Modal dialogs can be bypassed


    Not sure if this has been covered already but modal dialogs can be bypassed by simply using the tab key to cycle through all the underlying links, linked images and form elements on the page. For example, if you open a modal dialog on top of a form, you can press tab until you can access the elements behind the modal dialog/mask.

    This behavior has been replicated on FF2 and IE7 using 1.1b1 on Windows.

  2. #2
    Sencha - Ext JS Dev Team Animal's Avatar
    Join Date
    Mar 2007
    Location
    Notts/Redwood City
    Posts
    30,546
    Vote Rating
    62
    Animal has a spectacular aura about Animal has a spectacular aura about Animal has a spectacular aura about

      0  

    Default


    "modal" dialogs are just divs which have an opaque div placed under them that masks underlying elements from mouse events.

    Can you think of a workaround?

    Perhaps this before show:

    Code:
    this.reEnable = [];
    Ext.fly(document.body).select("input select a button").each(function(el) {
        if (!el.dom.disabled) {
            el.dom.disabled = true;
            reEnable.push(el.dom);
        }
    });
    and this after hide:

    Code:
    Ext.each(this.reEnable, function(el) {
        el.disabled = false;
    });
    ?

    Might be a bit of a performance hit finding and disabling every <input>, <a>, <select> and <button>.

    Should <map>/<area> be added to the DomQuery selector?

    Perhaps it could be added but made optional?

  3. #3
    Ext User
    Join Date
    May 2007
    Posts
    31
    Vote Rating
    0
    kato is on a distinguished road

      0  

    Default


    Thanks, Animal. I haven't deeply pondered on a workaround yet, as I was half-hoping that this issue has already been addressed. Your workaround seems feasible and sure worth the try, though it might indeed have some performance degradation on complex layouts/forms in the background, and also complications in nested modal windows. What I was pondering on was to listen for tab key presses and allow focus switching only within the elements of the current modal window (dialog or message box).

  4. #4
    Sencha User
    Join Date
    Apr 2012
    Location
    Austin, Texas
    Posts
    4
    Vote Rating
    0
    brian.moeskau is an unknown quantity at this point

      0  

    Default


    If you wanted to try something like this, you'd want to preserve the original disabled state of each element, rather than simply enabling them all after hide.

  5. #5
    Ext JS - Development Team J.C. Bize's Avatar
    Join Date
    May 2007
    Location
    Bay Area, CA
    Posts
    179
    Vote Rating
    0
    J.C. Bize is on a distinguished road

      0  

    Default


    I think you'd also want to run that first chunk of code *after* show (rather than before) so that even if there is a delay in disabling all the elements, the user will not notice it.

  6. #6
    Ext User
    Join Date
    May 2007
    Posts
    31
    Vote Rating
    0
    kato is on a distinguished road

      0  

    Default


    Yeah, and this might cause some complications in nested modal windows if not done right.

    I'm still leaning towards simply listening for tab key presses and limit the focus cycling/switching within the elements of the current modal window.

    A real modal window shouldn't be circumvented like this since this can actually break the application. I'm actually surprised that this issue hasn't been addressed or escalated.

  7. #7
    Sencha User
    Join Date
    Apr 2012
    Location
    Austin, Texas
    Posts
    4
    Vote Rating
    0
    brian.moeskau is an unknown quantity at this point

      0  

    Default


    A "real modal window" would also not be a div inside a page

  8. #8
    Ext User
    Join Date
    May 2007
    Posts
    31
    Vote Rating
    0
    kato is on a distinguished road

      0  

    Default


    I was describing how a real modal window "behaves" as it's obvious that Javascript modal windows are simulated. But you know what I mean. Having the modal attribute simply means you intended to simulate a real modal window right? Meaning you basically want to shield the rest of the underlying page from the user. So, why not make it behave as such?

    Does this mean that I'm the only one who's concerned that someone might break my application just by simply tabbing through the rest of page and pressing space/enter on the focused buttons? Try it out and you'll see what I mean.

    Here's a great example of implementing perfectly simulated modal windows: www.meebo.com so I don't see the sense why it can't be done with Ext.

    Aside from that, the entire UI feels very snappy and behaves almost like a true desktop app. The only drawback is I think it's developed in Dojo and leaks memory like hell, but the functionality and concept is great.

  9. #9
    Ext User
    Join Date
    May 2007
    Posts
    31
    Vote Rating
    0
    kato is on a distinguished road

      0  

    Default


    Anybody from the Ext team care to look into this? And hopefully not reply with things like "A real modal window would also not be a div inside a page" as if it were a constructive statement.

  10. #10
    Sencha User
    Join Date
    Apr 2012
    Location
    Austin, Texas
    Posts
    4
    Vote Rating
    0
    brian.moeskau is an unknown quantity at this point

      0  

    Default


    Note the denoting that it was a joke...

    We can look into it, but it's not the highest priority item on our plate right now. Unless anyone already knows of a super-simple, cross-browser solution that still allows for full keyboard navigation within the dialog itself... ?