JQUERY click handler from DIFFERENT element triggered on enter?

Question

URL is here: http://prorankstudios.com/sandbox/wtf/

Using IE9, with focus on the User or Pass field, hit the ENTER key...

Notice that this whole page reloads.

What's happening is that the click handler for the #live_site_link (assigned on line 30 of common.js) is running when no click has happened on #live_site_link at all...

Login Submit code:

    Login.Submit = function(e)
{
    Login.feedback.empty();
    if (Login.user.val() == '')
    {
        Camo.ErrorAlert('Invalid username.',Login.feedback);
        Login.user.focus().select();
        return false;
    }
    if (Login.pass.val() == '')
    {
        Camo.ErrorAlert('Invalid password.',Login.feedback);
        Login.pass.focus().select();
        return false;
    }

    Camo.AJAXStart('Logging in...');
    postData =
    {
        user:Login.user.val(),
        pass:Login.pass.val()
    }

    Camo.AJAXPost('index/login/',Login.Success,Login.Failure,postData);
    return false;
}

live_site_link click handler:

    $('#live_site_link').click(function()
{
    window.location.href = './';
});

In fact, the handlers for the login form (both a keyup and a click on Go button assigned in login.js lines 22 and 24 respectively) sometimes run AFTER the page has reloaded, strangely enough.

In IE7/compatibility mode, the keyup and click handlers for login_submit properly work and the page does not reload. This is also the case in all other browsers I tested.

What is IE9 doing?

That's not what's happening. the Submit function isn't being stopped in IE9. I don't know what Login.Submit does as far as CAMO CMS is concerned, but I'm willing to bet if you capture the event function(event), and use event.preventDefault(); it would most likely fix your issue. — Ohgodwhy, Mar 06 '12 at 04:01
If you look closer, there's no submit function to be stopped... there's no form tags to submit. Put a breakpoint on the common.js click handler for the live_site_link and you'll see it's triggering. IE9 only. — Rimer, Mar 06 '12 at 04:06
using $("#login_user").live('keypress', function(e){ var code = (e.keyCode ? e.keyCode : e.which); if(code==13){ e.preventDefault(); alert('Enter Invoked. Default behavior stopped.');} }); (Side note: Just noticed you had the jQuery 1.7 library in use, you can use $("#login_submit").on('keypress', function(e){ instead.) in the Console stops the page submit. If this is indeed the case, replacing the alert with whatever your login check is will stop this default behavior. Although I don't know what the unintended consequences are. — Ohgodwhy, Mar 06 '12 at 04:16
The click handler for the live_site_link is running BEFORE the submit handler, therefore it's too late to stop propagation when this weird problem occurs! — Rimer, Mar 06 '12 at 04:26
The reason I'm stressing this issue is because I'm fairly sure IE is treating the input field as a form element, and that the default behavior of the 'enter key' in an input field is to search for the nearest button and simulate a 'click' on it if it's not wrapped in a form. I tried this and duplicated the same issue within a local environment; moreover, using the keypress detection method I was able to stop the default behavior of IE9 (as I just described above) allowing me to display our message, 'Invalid Username' or 'Invalid Password' respectively. Cheers. — Ohgodwhy, Mar 06 '12 at 04:42
I still find it odd that it would reach out to find a button that was not within the same fieldset to press... However, you seem to be on to something because if I change that live_site_link button to an anchor tag instead, it no longer triggers its click handler when interacting with the form... — Rimer, Mar 06 '12 at 13:07
Have a look at this -> http://stackoverflow.com/questions/585396/how-to-prevent-enter-keypress-to-submit-a-web-form — Manse, Mar 06 '12 at 13:20

score 0 · Answer 1 · answered Mar 06 '12 at 04:01

0

Try calling e.preventDefault() or e.stopPropagation() before you return false in Login.SubmitOnEnter

It would be better though if you wrapped a form around your form elements, then attached an event for the form submit. That way it will still work without javascript and you wouldn't have to have a separate event for click and enter press.

answered Mar 06 '12 at 04:01

David Gallagher

723
4
8

Thanks for answering. That function does not run till well after the live_site_link click handler runs. put a breakpoint in common.js and see for yourself... it's redirecting to ./ via the click handler for the #live_site_link, which is no where near the login form... Also this site will be heavily reliant on ajax, so regular forms while nice, are moot. – Rimer Mar 06 '12 at 04:06
In that case I would certainly suggest changing to using the submit as @charlietfl has also suggested, even if your form will only use ajax. – David Gallagher Mar 06 '12 at 04:09
This would stop the erroneous click handler how? A completely different click handler is triggering than is expected given the situation. That is the problem here, not the lack of an HTML form... – Rimer Mar 06 '12 at 04:11

score 0 · Accepted Answer · answered Mar 06 '12 at 13:14

The only "fix" for this I could figure out short of changing the live site link button to a regular anchor tag was actually to enclose the login fields and button inside form tags.

Apparently without those enclosing form tags, IE9 is using the live_site_link button instead of the GO button to submit the form on a natural enter key press before the keyup handlers on the inputs and the click handler on the Go button of the login form ever get a chance to trigger, which causes the page to reload (as that's what the click handler for live_site_link does).

Now I have to handle logins without AJAX...

charlietfl · Answer 3 · 2012-03-06T04:19:51.207

-1

You would probably manage the login submittal process easier by using a submit handler rather than needing to catch enter key and make it click on submit button. Seems like extra code to work around doing it a simpler way

$('form').submit(function(){
    var valid=someValidionFunction();

   return valid;
})

Edited due to no ajax

edited Mar 06 '12 at 04:19

answered Mar 06 '12 at 04:07

charlietfl

170,828
13
121
150

There's no form to submit! I also find it to be a pain and "extra work" to have to handle both the ajax form submission as well as the natural HTML form submission, when the application will be so heavily reliant on ajax that it would make regular HTML form support moot... – Rimer Mar 06 '12 at 04:10
but you are using a fieldset which is for use in forms. I suspect IE expects it to be in a form – charlietfl Mar 06 '12 at 04:19
Ok, but regardless, why is a click handler for a button on the top left of the page being triggered when pressing enter within the input fields in that supposedly unrelated fieldset? – Rimer Mar 06 '12 at 04:23
the absolute same thing... the live_site_link click handler from common.js triggers. Again, it's a clickhandler for the button in the top left corner that is triggered when enter is pressed from within the input fields of the login form on the top right... This is not a form issue... it seems to be JQ or perhaps a glitch in HTML layout?? – Rimer Mar 06 '12 at 04:29
i think layout...now sure why use a button element for a link in top, swaitch to `` might stop it – charlietfl Mar 06 '12 at 04:34

JQUERY click handler from DIFFERENT element triggered on enter?

3 Answers3