9

I'm developing a web application which requires long-running Ajax requests. Unfortunately, under Firefox, pressing Escape during a request has the drawback of killing the request and any information it was holding. This is rather annoying, as this can lead to all sorts of nasty complications if this happens at the wrong time. Therefore, I would like to deactivate this feature.

My first reflex was to intercept keypresses at the boundaries of <body>, to ensure that they would not reach the window. For this purpose, I installed a [keypress] event handler, just for events whose [keyChar] is 27, and had it invoke [stopPropagation] and [preventDefault]. And for a time, it looked like this was working.

Then, I realized that it wouldn't work when the user hadn't clicked anywhere on the window, as <body> event handlers never received the event. I tried to attach my handler to <document> or <window> to no avail, so I eventually ended up adding a [load] event handler and had it force focus to <body>. And for a time, it looked like this was working.

Then, I realized that when the user was editing an <input>, for some reason, once again, the <body>, <document> or <window> event handler never seem to receive the event. So, I added yet another [keypress] handler, intercepting with [preventDefault] on the <input> when the [keyChar] is 27.

For the moment, it looks like it's working. However, with the history of this bug in my application, I'm a tad pessimistic.

So, I'm wondering if there's a better -- and reproducible -- method. Recall that the bug seems to appear only in Firefox, so I'm quite willing to take a Firefox-only approach here.

Brian Tompsett - 汤莱恩
  • 5,753
  • 72
  • 57
  • 129
Yoric
  • 3,348
  • 3
  • 19
  • 26
  • 1
    How exactly is `Esc` cancelling Ajax requests in the first place? I've never heard of this happening before. – Matt Ball Oct 07 '10 at 16:00
  • @Matt, if you have firebug, you'll notice that the connection is killed the very moment you hit escape. – Kirk Woll Oct 07 '10 at 16:11
  • @Kirk - wow, I do see that. Does it happen without Firebug, as well? – Matt Ball Oct 07 '10 at 16:28
  • Yes it does stop XHRs, even with firebug off. – Ruan Mendes Oct 07 '10 at 18:16
  • I don't understand why the event from a text field is not bubbling to the document. I tested it and it worked for me. Any other handlers on that input blocking it? – Ruan Mendes Oct 07 '10 at 18:18
  • @Juan: It doesn't look like any handler is blocking it. Indeed, the default behavior (killing Ajax) is triggered. But somehow, it doesn't bubble up through the usual path. – Yoric Oct 08 '10 at 09:18

2 Answers2

2

I'd be worried about other nasty complications that will happen when the users choose a bookmark or otherwise navigate away in the middle of the request. You might want to look at why you're using long running requests and see if that's something you can change...

If it isn't something you can change (or even if you can) you should look at why your requests aren't fault tolerant. Is there a way to put the communication into transactions, and roll the latest one back if the connection is interrupted?

Kendrick
  • 3,747
  • 1
  • 23
  • 41
  • 1
    BOSH and Comet are good examples that require long-running ajax requests. – Kirk Woll Oct 07 '10 at 16:00
  • Hadn't heard of them, but looking at BOSH, the protocol is supposed to be fault tolerant and be cabable of being split over multiple requests: http://xmpp.org/extensions/xep-0124.html#reqs – Kendrick Oct 07 '10 at 16:43
  • No, there's strictly no way we can get around long-running requests. We need to be able to push results from the server to the browser immediately -- and we can't afford to be compatible only with HTML5 browsers and WebSockets. But don't worry about the other nasty complications you mention, we have them handled. – Yoric Oct 08 '10 at 09:10
  • 1
    How about asking the users (nicely) not to press Esc :-) I don't know the app, but it seems that as long as ending a request isn't going to cause data integrity problems on the server side, capturing the key events is probably sufficient in this case. – Kendrick Oct 08 '10 at 14:33
  • ) Thank heavens, the server won't have data integrity problems. But `Esc` could possibly set the client is an inconsistent state, which is generally unacceptable. After all my patches, I can't reproduce the issue, so I'll cautiously mark it as "possibly solved". And hope that, if it isn't actually solved, users won't just start pressing `Esc`. – Yoric Oct 14 '10 at 08:14
1

I know this is kind of an old thread but there's an active bug logged against Mozilla regarding this issue (which I'm also facing). See https://bugzilla.mozilla.org/show_bug.cgi?id=614304 for more info.

One suggestion from this bug is to intercept and prevent the ESC key press at the window level (as also mentioned by OP):

window.addEventListener('keydown', function(e) {(e.keyCode == 27 && e.preventDefault())});

This might have unwanted side-effects though.

Christophe L
  • 13,725
  • 6
  • 33
  • 33