IE6 fires unexpectedly 'onclick' when pressing ENTER (keyCode 13)

[Prima]

Prolog:

I have an INPUT tag on the web page I currenty developing.
This input field observes 'onkeydown' event and handler for this detects keyCode for ENTER.
After that it replaces itself with SPAN tag.

Simple and clear.
----

Problem description:

But sometimes (not frequently) after pressing ENTER and making SPAN replacement it fires also 'onclick' event. And it fires this on an delete BUTTON (image) which stays far from that INPUT/SPAN place on this page.

Event handler for that delete BUTTON shows that this event object has negative values for offsetX and offsetY properties.

Could you give me any suggestions or keywords, why this 'onclick' takes place ?

Maybe this caused by tabIndex issue ?

[~s.o.s~]

This sure is a weird problem; without looking at the code, it would be kind of difficult to arrive at a solution. BTW, how are you attaching event listeners to your components? Are you using attachEvent / addEventListener or the plain old way of attaching events?

[Prima]

Yes, I have produced an simple example!

http://www.hot.ee/mocambo/test_input_ie.html

It's clear now that under IE every input tag with type=text by ENTER press fires click event on nearest / newest input tag with type=image.

How to prevent this ? Where IE stores this reference to this button ?

[Prima]

Some adjustments:

1.
Detecting event.keyCode == 13 -> event.returnValue = false doesn't help some times (when I have lots of working event handlers same time), it still fires button.

2.
Where IE stores reference to this button ? Maybe it's possible set NULL to this reference or what if I want fire another button instead first one ?

[~s.o.s~]

Yes, there does seem to be some weird mumbo jumbo going on there. It seems that pressing the RETURN key causes the button to be pressed and hence the x=0&y=0 values in the querystring. One solution I can think here is to enclose the entire thing in a FORM tag (the way it actually should be; form elements like text fields ought to go inside a FORM tag). This makes sure you don't fire off fake onclick when a return key is pressed in the text field.

I guess a better solution here would be to try to approach the problem from a different perspective and to use normal IMG tags with an onclick attribute rather than using an INPUT tag with type image . Maybe using some simple Javascript library like DOM assist for dynamically adding elements and event handling would simplify your task a lot.

[Prima]

Thank you !

I have detected:

1. That click on Button1 is default behavior on INPUT tag (type=text) after ENTER pressed. ( Prevent this using event.returnValue = false )

2. That Button1 will also clicked when ENTER pressed on document.body .

Anyway ... for educational purposes it's good to know, where IE stores reference to this Button1 (and not to Button2). Seems that when FORM block is missing, this reference stored somewhere in document (not in each separate input field) as default behavior.

This sample was simplified and JS frameworks are cutted out. I try to fit my current working W3C standards project to IE standards. Main purpose doing this with minimal changes in existing code. Change something is bad, add something IE specific is good.

[~s.o.s~]

> Anyway ... for educational purposes it's good to know, where IE stores reference to this
> Button1

Not sure if I understand this correctly, but there is no reference stored, only the default action executed when the RETURN key is pressed inside the INPUT field which is submitting the form. Same happens when you have a text field along with a SUBMIT button.

>I try to fit my current working W3C standards project to IE standards.

Tough luck I guess. :-)

[Prima]

Solution (simple as always):

Only 'document' element fires 'click' behavior on ENTER key press.

Therefore we should catch ENTER press with 'onkeydown' event handler on 'document' element. We don't need to catch ENTER on every text-type INPUT field.

Tough luck I guess. :-)

This was hopefully my last IE6 specific fix.

Thanks for your support ~s.o.s~ ! :)

[~s.o.s~]

> Solution (simple as always):

Oh yes, the KISS paradigm.

> Thanks for your support ~s.o.s~ !

You are of course welcome. :-)