3

I am trying to "feature detect" IE's behavior when pressing enter in an input box that has a button element next to it (when they are not in a form element).

I'm saying IE's behavior because no one else fires a click event on the next button when pressing the enter-key while the input is focused.

Related question where the first awnser describes why IE behaves like this: IE bug triggers click for 2 buttons?

JS-Fiddle where I try to simulate the key press via jQuery.Event and .trigger: http://jsfiddle.net/DbVrn/

Behavior of said js-fiddle in IE:

  • When opening the page, the input gets focus, and then we try to simulate pressing of the enter-key.
  • The simulated enter-key does nothing, hence the input remains focused and red.
  • If you manually press enter while the input is focused, the button will become focused and green.

The problem i have with my current attempt to detect this feature is that:

$("input").trigger(jQuery.Event("keypress", { which: 13 }));

does not actually do the same as manually pressing the enter-key while the input is focused.

How can I successfully simulate the enter-key so that my test for this behavior is possible? Or is there another way i can test for this behavior?

Edit: Updated title to more clearly state that this needs to be tested via javascript, and that the test needs to work in IE from version 8 to 10. Unless anyone else can provide a way of testing this, I will conclude that I need to use user-agent sniffing to see if browser is IE and choose code-path based off that.

Community
  • 1
  • 1
Sense545
  • 494
  • 4
  • 14
  • Why is this important to detect? What's the background? – Ja͢ck Jan 21 '13 at 10:29
  • I need to detect this so that i can add an event that does `e.stopPropagation()` if `e.which === 13` if inputs behave like that. Used `if ($.browser.msie) { ... }` before, but `$.browser` is no longer part of jQuery.. – Sense545 Jan 21 '13 at 10:50
  • So what if it triggers a click on the next button? Unless it's a submit button, but you shouldn't use buttons outside of a form in the first place .. perhaps I'm missing something? :) – Ja͢ck Jan 21 '13 at 10:51
  • I'm developing an application framework and controls, and use – Sense545 Jan 21 '13 at 10:57
  • If you want to check for IE you can always use `window.navigator.appName` – Johan Jan 21 '13 at 11:39
  • I do not want to check for IE, i want to check/test if the browser behaves the way i described. – Sense545 Jan 21 '13 at 12:00

3 Answers3

1

Neither by using jQuery's trigger method nor by using the native methods it is possible to simulate key presses in the way that you would like to. The real and simulated key presses can both be captured, but the simulated key presses do not trigger the entire chain of event handlers that are caused by a real key press. This is easily demonstrated by putting this line above your trigger

$("input").keypress(function(event) { alert(event.which); });

As you can see the capture works fine, for both simulated and real key presses, while the difference between the handling of those two key presses obviously remains.

It also does not matter what you do with your keypress event objects. You may add a keyCode, which the real keypresses in IE have, but this will not change this. It seems nothing will. Unfortunately I cannot find any documentation explaining why, though this problem has been around for a while

http://forums.asp.net/t/1478871.aspx/1

So there seems to be no way from within the browser. You would have to do it from without. You could use something like InternetExplorerDriver for that.

Instead of feature detecting I would recommend simply recording which user agents have this 'feature'. Since Microsoft is usually pretty bend on backwardscompatibility it is unlikely they will change the behavior of an enter keypress on an input field in future version.

http://code.google.com/p/selenium/wiki/InternetExplorerDriver

Simulating key presses that change input/textarea fields

Using the TextEvent method it is possible in some browsers (e.g. chrome) to send text, including new line, to an input or textarea field, but this will not work in any version of IE up to version 10 as demonstrated by this fiddle:

http://jsfiddle.net/qz7kV/1/

Lodewijk Bogaards
  • 19,777
  • 3
  • 28
  • 52
  • Thank you for your response. Sadly I am coming to the same conclusion, that I need to do user-agent sniffing. – Sense545 Jan 22 '13 at 08:46
  • Yes, it took me quite a while to reach this conclusion as well. It's hard to proof a negative. "It cannot be done", seems to be the right answer. – Lodewijk Bogaards Jan 22 '13 at 09:02
  • BTW It also does not matter if you put the events in the right order, as in keydown, keypress and then keyup. It is simply not possible. – Lodewijk Bogaards Jan 24 '13 at 19:42
1

It seems there is no way to test for this behavior via JavaScript. I have tested IE 8, 9 and 10 and confirmed they all behave this way.

So for now, i am going to combine some ideas from Javascript IE detection, why not use simple conditional comments? and http://tanalin.com/en/articles/ie-version-js/ to create a test for IE that will work reliably as long as IE does not remove support for conditional compilation comments.

var ie = (/*@cc_on!@*/false && (function(){
    var div = document.createElement("div"),
        list = div.getElementsByTagName("br"),
        version = 3;
    do {
        div.innerHTML = "<!--[if gt IE " + (++version) + "]><br><![endif]-->";
    } while(list[0]);
    return (version > 4 ? version : 10);
}()));

The ie variable will be the browser version in Internet Explorer, and will be false in other browsers.

Community
  • 1
  • 1
Sense545
  • 494
  • 4
  • 14
0

I don't see a reliably way to trigger the bug from JavaScript alone. You have several other options:

  1. Install IE in a VM and use a UI robot to drive the test. That takes a lot of effort but will reliably trigger the bug.

  2. There are companies which offer remote testing; they use SSH tunnels to access a server on your side and can test your site against many different versions of IE. This is pretty easy to set up technically but might be hard to get because of company policies, FUD and politics. Google for "test web site with many different browsers"

  3. Test it once manually and when it works, write a test case which just checks that the code is there (i.e. a test that fails when the JavaScript file or page source doesn't contain a certain fixed string). Pro: Very easy to set up, Con: Breaks easily

  4. Just test it once and then rely on inertia (i.e. that no one else will touch that code for years).

Aaron Digulla
  • 321,842
  • 108
  • 597
  • 820
  • Thank you for your response, but the point was to test for it when the page loads and use a code path that fixes the behavior, so testing externally is no help. I guess I'll have to use user-agent sniffing. – Sense545 Jan 22 '13 at 08:33
  • Sorry, I was under the impression you wanted to unit test your fix, not detect the presence of the bug. As I said above, triggering UI bugs in a browser from JavaScript is rarely possible. User-agent sniffing is probably the only solution. – Aaron Digulla Jan 22 '13 at 11:43