Ticket #6759 (new defect)

Opened 4 months ago

Last modified 2 months ago

keypress problems in a TextBox on a dialog, launched from a dialog

Reported by: lloydmurray@… Owned by: becky
Priority: high Milestone: 1.3
Component: Accessibility Version: 1.1.0
Severity: normal Keywords: Dialog TextBox model keypress onkeypress
Cc:

Description

I'm trying to launch a dialog from a dialog. On the second dialog with a textbox, I'm having problems with keypresses. Under IE7, I can't type in that textbox at all, while in FF2, I can type, but can not hit back space. This seems to be new in dojo 1.1.x. (Tried in 1.1.0 and 1.1.1) This was working in previous versions of dojo. 

<html>
    <head>
        <style type="text/css">
        /* <![CDATA[ */
            @import url("http://o.aolcdn.com/dojo/1.1.1/dojo/resources/dojo.css");
            @import url("http://o.aolcdn.com/dojo/1.1.1/dijit/themes/tundra/tundra.css");
        /* ]]> */
        </style>

        <script type="text/javascript">
        // <![CDATA[
            djConfig = { isDebug: false, parseOnLoad: true };
        // ]]>
        </script>
        <script type="text/javascript" src="http://o.aolcdn.com/dojo/1.1.1/dojo/dojo.xd.js"></script>
        <script type="text/javascript">
        // <![CDATA[
            dojo.require("dojo.parser");
            dojo.require("dijit.form.Button");
            dojo.require("dijit.form.Form");
            dojo.require("dijit.form.ValidationTextBox");
            dojo.require("dijit.Dialog");

            function openDialog1() {
                dijit.byId("test1").show();
            }
            function openDialog2() {
                dijit.byId("test2").show();
            }

            dojo.addOnLoad(function() {
                var foo1 = new dijit.Dialog({ title: "test1 dialog" },dojo.byId("test1"));
                foo1.startup();

                var foo2 = new dijit.Dialog({ title: "test2 dialog" },dojo.byId("test2"));
                foo2.startup();
            });
        // ]]>
        </script>

        <title>dialog test</title>
    </head>

    <body class="tundra">
        <td id="dialogButtonCell"><button id="dialogButton" dojoType="dijit.form.Button" type="button" onClick="openDialog1();">Open Dialog</button></td>
        <div id="test1">test content 1 - press button to open another dialog
           <input type="text" dojotype="dijit.form.ValidationTextBox" size="25" value="test1">
           <button id="dialogButton1" dojoType="dijit.form.Button" type="button" onClick="openDialog2();">Dialog2</button>
        </div>
        <div id="test2">test content 2 - try typing, and backspacing in FF and IE.
            <input type="text" dojotype="dijit.form.ValidationTextBox" size="25" value="test2">
        </div>
    </body>
</html>

Attachments

dialog_test.html (2.1 kB) - added by guest 4 months ago.
Test of error condition
multipledialog.patch (1.7 kB) - added by becky 3 months ago.

Change History

Changed 4 months ago by guest

Test of error condition

Changed 4 months ago by guest

added by lloydmurray@…

Changed 3 months ago by bill

  • reporter changed from guest to lloydmurray@gmail.com

We really don't support launching a Dialog from another Dialog. (I've seen bug reports about this before and written the same thing, but can't seem to find them now.) Not sure if that's related to your problem at all. Can you make a simpler test case that doesn't have the nested dialogs?

Changed 3 months ago by guest

This log is about using dialogs from dialogs. I can't scale back the test any more then what's attached. We have been using dialogs on dialogs within our application (from dojo 0.3.x) since Dec 2007. We did some hacks with setting the Zindex appropriately. Can you give me some pointers on why this might not work? Are there any known work-arounds? thanks, Lloyd

Changed 3 months ago by bill

Hmm, if the problem was IE6 my first suspect would be the iframe created as part of the DialogUnderlay (search for !BackgroundIFrame in Dialog.js). However, that's only there for IE6, not IE7 or FF.

Maybe it's got something to do with the fade-in of Dialog? You could try modifying Dialog.js to just display the dialog and it's underlay to see if the problem goes away...

Changed 3 months ago by guest

I tried setting the duration to 0 in Dialog.js, and that didn't help. I then removed the fade-in/out code from Dialog, and that didn't help this problem. (It did make the Dialogs appear "faster"). Any other ideas? Maybe I'll diff Dialog.js from 1.1.0 to 1.0 and see what other changes took place. Think anything in the _onKey function could be doing this?

thanks again, Lloyd

Changed 3 months ago by guest

If I comment out the dojo.stopEvent(evt) line in _onKey() in Dialog.js (line 309 v 1.1.0), that will fix this problem.

<code> // this key is for the disabled document window if(evt.keyCode != dojo.keys.TAB){ // allow tabbing into the dialog for a11y

//dojo.stopEvent(evt);

// opera won't tab to a div }else if(!dojo.isOpera){ <code>

This has the unfortunate side effect of allowing me to Tab to other dialogs. Any thoughts?

Lloyd

Changed 3 months ago by guest

This has the unfortunate side effect of allowing me to Tab to other dialogs. Any thoughts?

...and it allows me to tab back to the base screen, so I wouldn't consider this a "fix".

Changed 3 months ago by bill

That's a good discovery. (BTW you can quote code in this system with triple left curly brace to start, and right curly brace to end it. <code> is for drupal I think). As per:

Any thoughts?

My thought is... why is that stopEvent(evt) getting called when you type normal characters or backspace? It's only supposed to be called on the tab key.

Changed 3 months ago by guest

That stop event is being called when the matching parent dialog is never found. (It's a != TAB, not an == TAB).

To fix this correctly on a dialog on a dialog, there should be a tracking means for which dialog is "active". Then, the connect/disconnects methods for the onKey could be called for the inactive dialogs. (This would ensure the _onKey is only ever called on the active dialog). For a quick fix, I added the following, right above that code I commented it, but after the while loop. 

                 if (!node) {
                        return;
                    }
                    // this key is for the disabled document window
					if(evt.keyCode != dojo.keys.TAB){ // allow tabbing into the dialog for a11y
						dojo.stopEvent(evt);
                    // opera won't tab to a div

}

I'd test this through the browsers to make sure it works properly.  (I checked it on FF2 and IE7)  One more note.  This will only work if the firstFocusItem and lastFocusItem are correctly set.  Sometimes, it seems, these are set to odd dialog span, or other "un-tabbable" items, which will allow the you to Tab back to another dialog, or the main screen.

Changed 3 months ago by bill

  • owner set to becky
  • component changed from Dijit to Accessibility

Ah I see. OK well sounds like you found a solution.

I'm not sure that the if(evt.charOrCode != dk.TAB){ block of code is even used anymore though, now that we have code to find the first focusable item in a Dialog (assuming there is one) and move to it. Passing this over to Becky because if that code isn't needed anymore then we should delete it.

If not, then I don't really want to put in code to track which Dialog is active, so might mark this as wontfix.

Changed 3 months ago by guest

We'll, I found a solution that requires us to patch your code, then check when updates come. We'd like to get away from doing this in every release, that's why I posted this up there. With this solution, and a mechanism to automatically set the zindex on a dialog show, you'll be able to support multiple dialogs in dojo/dijit. This seems to be well wanted on the forums.

keep me updated. thanks! Lloyd

Changed 3 months ago by becky

Changed 3 months ago by becky

multipledialog.patch fixes the multiple dialog problem as well as an existing bug where the use can click off of the dialog and thus lose focus in the dialog. I added a trap of mousedown in the dialogunderlay and modified the dialog to only listen for keyevents within the dialog itself rather than the documentElement. It needs more testing to make sure I didn't cause any regressions.

Changed 2 months ago by becky

  • milestone set to 1.3

the simple fix will not work. multipledialog.patch still has issues on IE if the user clicks outside of the dialog. I am moving this to 1.3 since it won't make 1.2 due to the IE issues and further discussion about whether or not we should support launching a dialog from a dialog.

Note: See TracTickets for help on using tickets.