Enter key on dialog "close button" results in enter key processed by other widget

[Open eSignForms]

I have a dialog box, with a close button that is given the focus so
that hitting Enter results in it closing.

That works fine. In fact, it seems that the Enter actually results in
a Click event, perhaps because it's a button receiving the key.

But my onClick handler sets the focus on an input TextBox field on the
form "under it" that cause the error. This then seems to cause the
onKeyUp key to fire on that TextBox. I don't want this since the key
actually was hit on the dialog box.

If my dialog box doesn't set the focus back, this doesn't seem to
happen. But when it does set the focus back, it seems to cause the
Enter to also be sent to it.

What am I doing wrong?

[Dalla]

This sounds wierd. Are you saying that an event is being fired when a
user hits the enter key with focus on a button,
without you having registered a onKeyDown, onKeyPress or onKeyUp event
handler for that button?

If the onClick event is fired when you hit enter on the keyboard, it
sounds like on of the above event handlers (probably onKeyDown or
onKeyPress)
is firing a programmatic click event.

[Thomas Broyer]

Probably nothing; it's not clear what browsers should do (and are
doing) when you change the focus during key events' handling
(particularly, when you change focus during keydown or keypress,
should the next keypress and keyup fire on the original target or the
newly focused element? and the same applies somehow for push buttons,
radio buttons, checkboxes and dropdowns; as you've been experiencing).
FYI, this is being discussed at the W3C.

What if you setFocus() in a DeferredCommand? that way, the focus
wouldn't have already been moved when the keyup event fire (so it'd
fire on the button, not the text box)

[gwtfanb0y]

Can you provide us the code where you assign the KeyListener to the
button? This makes it easier to analyze the problem.

[Brandon Tilley]

I agree with Thomas, this sounds just like something that could be
handled with a DeferredCommand. See
http://stackoverflow.com/questions/691684/gxt-keylistener-componentkeydown-immediately-closes-messagebox-alert
(the post is GXT-related but the general idea is the same).

[Yozons Support on Gmail]

It seems that it doesn't really matter.  The DialogBox itself works fine, and whether I call setFocus() immediately or through a DeferredCommand, the result is the same.

What is not clear is why there is a KeyUp event fired at all.   I am not even listening for keyup in the dialog.  I just have a close button that I give the focus to, so when Enter is pressed, it "auto-clicks" the close button for me.  This I see is working as expected because I get an onClick event sent to my button.

I removed the setFocus() call in the onClick() event handler of the dialog's close button, and then it fires the onClick event as expected and I see no KeyUp event.

But if I put the setFocus() call in the onClick() event handler of the dialog's close button, it first fires the onClick event as expected, but I then get a KeyUp event on the TextField that received the focus (it does have a KeyUp handler registered).

Here's the close button's onClick code:

        closeButton.addClickHandler(new ClickHandler() {
            public void onClick(ClickEvent event) {
                Object src = event.getSource();
                GWT.log("ExceptionDialog onClick source: " + src.getClass() + "; event: " + event.toDebugString(),null);
                dialog.hide();
                if ( giveFocusBackTo != null )
                {
                    DeferredCommand.addCommand(new Command() {
                        public void execute() {
                            giveFocusBackTo.setFocus(true);
                            giveFocusBackTo = null;
                            return;
                        }
                    });
                }
            }
        });

If I comment out the giveFocusBackTo.setFocus(true), it works as expected, but when I return from the dialog, my field doesn't have the focus that I'd like it to have.    If I have it like above, I'll get both an onClick and a KeyUp event:

[INFO] ExceptionDialog onClick source: class com.google.gwt.user.client.ui.Button; event: event: ClickEvent:
[INFO] myhandler keyup source: class com.google.gwt.user.client.ui.PasswordTextBox; event: event: KeyUpEvent:[13];

So the question is why does setting the focus in the dialog box cause a KeyUp event to fire, but if I don't do the focus, only the click occurs and no keyup event occurs?

[Thomas Broyer]

On 11 nov, 02:40, Yozons Support on Gmail <yoz...@gmail.com> wrote:
> It seems that it doesn't really matter.  The DialogBox itself works fine,
> and whether I call setFocus() immediately or through a DeferredCommand, the
> result is the same.

That's weird! This means the "click" of the button isn't triggered by
the keyup by the browser but by some other event (keydown, or keypress
or equivalent). It means that even if you used a Timer to delay the
setFocus a bit more than what the DeferredCommand do it wouldn't work,
for instance if you keep the key depressed before releasing it (the
timer could fire before you release the key).

> What is not clear is why there is a KeyUp event fired at all.   I am not
> even listening for keyup in the dialog.  I just have a close button that I
> give the focus to, so when Enter is pressed, it "auto-clicks" the close
> button for me.  This I see is working as expected because I get an onClick
> event sent to my button.
>
> I removed the setFocus() call in the onClick() event handler of the dialog's
> close button, and then it fires the onClick event as expected and I see no
> KeyUp event.

[...]

> So the question is why does setting the focus in the dialog box cause a
> KeyUp event to fire, but if I don't do the focus, only the click occurs and
> no keyup event occurs?

You set the focus while the key is down, so when you release it, a
keyup event is fired, and because the focus is on the textbox this
event is dispatched to the textbox. If you don't move the focus, the
keyup event is fired at the button, but you don't listened keyup
events there, so you don't see it.

That's just how your browser work, and as I said, this kind of
behavior is being discussed at the W3C (so future versions of browsers
will hopefully align on a predictable behavior).