Escape Key in Browser

[Salman Hemani]

Hey Everyone!

As you are aware that the browser uses the escape key to STOP the
loading of a page. I was wondering if there was a way to capture this
key and prevent the browser from getting the event. Well obviously I
am capturing the key because I overload this key to use it with my
application, but capture it before the browser gets it and never pass
it onto to the browser. Maybe someone can explain how the event
sequence actually works. I understand that I will not get the key
event if the browser does not get it first. But after it passes it
onto my application can I consume the event or is it that the browser
will first process it before sending it to the application?

Thanks!

[walden]

> key and prevent the browser from getting the event. Well obviously I

Look for DOM.eventPreventDefault(). Not sure if it works in this
case, but it may.

[Salman Hemani]

Thanks for the tip. I tried it and it does work.

I test to check if it is the Escape key then I use the following piece
of code:

DOM.eventPreventDefault(DOM.eventGetCurrentEvent());

However, I will have to trap this for every single item which listens
for a keyboard listener and prevent it from being passed to the
browser even on text fields. Also, when the focus is on the root panel
and not on any of the widgets that have a keyboard listener attached
to it, the browser will still process the event. I was hoping I could
attach a keyboard listener on the root panel but that is not an
option. Any other ideas or suggestions?

[Axel Kittenberger]

DOM.addEventPreview is for you. You will receive *all* events there.

[Salman Hemani]

Ok So thanks for that tip also and I sorta got it to work but I think
I am a little puzzled. I have the event preview listener and I can
capture the escape key. So if any components that don't have a
keyboard listener attached will not do anything ofcourse and so I can
successfully discard the event within the onEventPreview function.

But not all events are discarded because the components on which I do
have a KeyboardListener (list list and checkboxes etc) or a
ClickListener (like buttons) will still get the event. Which is great
because I can do what I want to do with it. So my question is two
fold:

1. Why do these other components also get the event? Isn't the
discarding of an event a global phenomenon? Or is it ignored for those
components that have a Keyboard Listener attached?

2. How can I handle other scenarios for which I don't have a custom
listener. Do I have to explicity attach a keyboard listener for
everything (which I think will work).

I would appreciate it if someone could explain me the flow of the
events.

Thanks a bunch for all the input so far. It has really helped! Almost
there!

On Mar 12, 10:45 am, Axel Kittenberger <axe...@gmail.com> wrote:
> DOM.addEventPreview is for you. You will receive *all* events there.
>

> > > case, but it may.- Hide quoted text -
>
> - Show quoted text -

[Jason Essington]

you may also want to look into DOM.eventCancelBubble()

-jason

[Peter Blazejewicz]

hi,

I think all inputs are wrong in what you are trying to achieve,
"ESC" is valid only before page fully load, You want to trap that key
event but you forgot that GWT code is initalized and set after page is
loaded,
After load event you of course can trap ESC key and use it in
application (some GWT widgets e.g. from incubator use ESC hit to
cancel/hide something),

regards,
Peter

[Salman Hemani]

Hi Peter,

The thing is that I am using a streaming service that pushes data from
the server (comet technique) so that this connection never dies. The
browser sees it as a continuous page load. So the ESC key is still a
valid input at that point. And when the user does hit escape it is
equivalent to a stop which kills the streaming service HTTP connection
which is what I am trying to prevent. The way I have accomplished this
so far is by implementing a Keyboard listener on any widget that
listens for keyboard inputs and preventing the default browser
behaviour for the ESC key. These widgets could be buttons, list,
checkboxes etc.

But there are still other places like the slider bar which can break
this connection. (I am not sure of this scenario because I cannot
reproduce it consistently). But it is something else that is listening
to the keyboard listener and not ignoring my event (maybe it's the
scroll panel), which is why I am questioning the sequence of events of
a key press.

What I want to clearly understand is this. When an ESC key is pressed,
how is the event distributed. So which of the following is true:

1. If the escape key is pressed on a text field does it start bubbling
upwards to the parent all the way to the browser or
2. Are there two events one for the browser and one for the text field
but the text field one is executed first giving me the chance to do
what I want to do (including preventing the firing of the second
event).

Or is it that both are incorrect and the browser handles this in a way
that I do not understand.

Thanks!


On Mar 12, 5:20 pm, Peter Blazejewicz <peter.blazejew...@gmail.com>
wrote:

> > Thanks!- Hide quoted text -

[Axel Kittenberger]

Why not use a RPC/AJAX in background connection? (or multiple always
reopening...)

[Peter Blazejewicz]

hi,

this won't be working cross-browsers I'm sure because they differently
shows comet requests "progress",
Also I think you're trying to cook feature which is againts user in
very deep concept. What about if other process causes browser to show
loading progress so user is legitimated to kill it just because she
does? Is that page to be run in controlled manner (well known user
base)? if so just let them know that background process is part of
applicaton and provide obvious UI element to kill comet requests from
GUI part still letting them to have a choice,

regards,
Peter

[Salman Hemani]

The RPC/AJAX mechanism is also present. It is used when the user
requests something but the streaming service is used when anything on
the server side changes from any other interface (web or non-web ui)

> > > - Show quoted text -- Hide quoted text -

[Salman Hemani]

Hey Peter,

Yes this application is to run in a controlled environment. But
telling them NOT to press the escape key will only provoke them to do
the opposite. :)

It would be easier to tell them this if the escape key was not what we
wanted to use. But we do require the use of the escape key because it
is intuitive to use it in a certain context. However, if the focus is
on the wrong place and they accidently hit escape it will cause the
application to break.

I am not preventing the escape from happening on the browser entirely.
They can hit stop or put the focus on the address bar and hit escape
and that would perform the correct behaviour as any user would expect.
I am just preventing the browser from getting the escape key when they
are in the context of the application.

We also have provisions that if they do accidently hit the escape key,
the streaming service will automatically detect the connection loss
and reestablish the connection.

Anyway I have solved most of my problems and the prevented the user
from hitting escape within the application. It wasn't too bad based on
the suggestions that were made in the earlier posts although I still
have not received the answers to my questions!! :)

The only place where I need to trap this key event is on a scrollable
area. For some reason If I focus on the scroll area and hit escape it
breaks stops the connections and if I can get that going I am set! So
if you guys have any other ideas to prevent this from happening on the
scroll panel I would love to hear from you!

Thanks!

[Axel Kittenberger]

Make a second RPC/AJAX background connection to get news from the
server. The server can hold the answer until something is to be shown,
or create an "nothing happened" answer every say 60 seconds so the
connection does not timeout. the client just reoppens the news
connection whenever he received an event or a non-event.

We did something like this for chatting, it works very well.

[Salman Hemani]

How is that different than the streaming service? Isn't that the same
thing?

[Axel Kittenberger]

Lets start with the ESC doing no harm, without any hacks :-)

(Also there are less issues with browsers dropping the one streaming
connection..)

[Salman Hemani]

Hey Axel,

I don't see any difference between your solution and what we have
implemented. Although you idea would work for an application that can
afford the opening and closing of connections, because our application
runs on an embedded device it is quite expesive to open and close HTTP
connections and slows down the backend.

The streaming service is initiated by the client and kept alive by the
server until the server detects a client connection has dropped in
which case it will reconnect to recover from the failure. The reason
why this second connection is a permanent connection because all
connected clients can get updates from other user interfaces or any
other connected client.

Maybe there is a method to your madness which I may not understand. :)
Can we connect via phone or chat and maybe we can discuss it out?

As far as the ESC key is concerned, no hacks! Just implementing the
features exposed to us by GWT. :-)

On Mar 15, 7:56 pm, Axel Kittenberger <axe...@gmail.com> wrote:
> Lets start with the ESC doing no harm, without any hacks :-)
>
> (Also there are less issues with browsers dropping the one streaming
> connection..)
>

> On Mar 15, 6:21 pm,Salman Hemani<salman.hem...@gmail.com> wrote:
>
>
>
> > How is that different than the streaming service? Isn't that the same
> > thing?
>
> > On Mar 15, 6:27 am, Axel Kittenberger <axe...@gmail.com> wrote:
>
> > > Make a second RPC/AJAX background connection to get news from the
> > > server. The server can hold the answer until something is to be shown,
> > > or create an "nothing happened" answer every say 60 seconds so the
> > > connection does not timeout. the client just reoppens the news
> > > connection whenever he received an event or a non-event.
>
> > > We did something like this for chatting, it works very well.
>

> > > On Mar 14, 8:28 pm,Salman Hemani<salman.hem...@gmail.com> wrote:
>
> > > > The RPC/AJAX mechanism is also present. It is used when the user
> > > > requests something but the streaming service is used when anything on
> > > > the server side changes from any other interface (web or non-web ui)
>
> > > > On Mar 13, 12:40 pm, Axel Kittenberger <axe...@gmail.com> wrote:
>
> > > > > Why not use a RPC/AJAX in background connection? (or multiple always
> > > > > reopening...)
>

[Axel Kittenberger]

I don't consider it madness... Its a pretty standard-comfort way, in
my humble opinion open HTML streams is much more a hack, which often
enough has been a source for error and incompability (and is also
AFAIK not standard comform), eating up server ressources and so on,
for me that is madness. But lets settle on it being a matter of taste
anyhow.

As said we did create a chat that way that works very well, all
messages send by users get an ID, every client will get messages from
the server always opening a connection for a message. It doesn't
matter when clients get out of sync, disconnect/reconnect and so on.

Don't feel the issue pushed upon you, but an alternative shown on how
it is IMHO "normally" done (on Desktop), and why these people don't
have these loading / canceling / breaking problems ... :-)

[Axel Kittenberger]

Message ID, That is ment, a client having message id # 84 at last,
will ask for id #85 and so on, until the server holds the connection
when the client is on top of events. If nothing happens for say 5
minutes, he gets a "nothing happened" answer, so the browser will not
timeout the connecton. This will work with all browsers and survives
very well plug out network cable, replug network cable or even change
IP events.

[Axel Kittenberger]

Sorry for the tripple post, but you can just google "AJAX Chat" and
you will see a lot non-GWT ajax applications working just that way.
Thats nothing "original" developed here :)

[Salman Hemani]

Thanks for your suggestions Axel. I will take a look into it.