Bug Tracker

Opened 14 years ago

Closed 14 years ago

Last modified 11 years ago

#134 closed enhancement (fixed)

Trigger browser event

Reported by: john Owned by:
Priority: major Milestone: 1.1a
Component: event Version: 1.1a
Keywords: Cc:
Blocked by: Blocking:

Description (last modified by john)

If you trigger an event $(...).submit(), .focus(), .blur(), .select(), .click(), etc. It should trigger the DOM Element's internal event function.

For example:


would also trigger:


(if it exists)

Change History (13)

comment:1 Changed 14 years ago by john

Priority: majorminor
Type: bugfeature

comment:2 Changed 14 years ago by joern

getAttribute, setAttribute and removeAttribute and handled by attr() and removeAttr().

submit() and reset() should be added later...

comment:3 Changed 14 years ago by john

Description: modified (diff)
Priority: minormajor
Summary: Some DOM methodsTrigger browser event
Type: featureenhancement

comment:4 Changed 14 years ago by john

Component: coreevent
Milestone: 1.1
Version: 1.1

comment:5 Changed 14 years ago by joern

What happens when calling this?


Currently, events bound to the submit event are called, nothing else. If the submit method of the form element itself is called, too, what happens to those handlers? They aren't triggered by the programmatic submit, so they can't prevent or handle the actual submit. And calling the handlers first, the method second or otherway round won't solve that problem, the association is simply lost.

And focus(), blur() and submit() (click and select, too?) have all in common that there can be only one element at once, that is, you can submit only one form, and focus or blur only one element. I don't see what we gain by handling those with jQuery methods.

Therefore I propose to close this ticket as invalid.

comment:6 Changed 14 years ago by sam

Maybe handlers should be triggered and the form submitted (or element clicked etc) only when none of the handlers return false. i.e. pseudo code:


Triggers the following

var fireEvent = true;
foreach(eventhandler in eventhandlers)
    if(!eventhandlers[eventhandler]()) fireEvent = false;
if(fireEvent ) jQuery(this)[0][event]();

Like joern says though, you can only submit one form, click one link etc, so $("form").submit() and $("a").click() would only run on the first form or anchor found.

comment:7 Changed 14 years ago by Dave

Normally I have either 1) a form with an onsubmit handler and a submit button the user presses, or 2) a form with no submit button but some other scheme to invoke a handler when the form changes. In # 1 the submit handler validates the form and returns true/false to decide whether to submit. In # 2 the handler validates the form and only calls form.submit() if the form is ready to submit.

Are there cases where the proposed additions would help? I don't think they're needed for case 1 or 2 above.

comment:8 Changed 14 years ago by blair

I don't think this is a valid feature. In the case of submit for example, the bound events are usually meant to replace or buffer the normal submit event.

comment:9 Changed 14 years ago by anonymous

If the handler of a click does not return false, I think that now the default handler is triggered, isn't it? So what is John saying? That the default handler should be called anyway? mmm... I hope not.

comment:10 Changed 14 years ago by Alex Cook

Actually, if I type $("#foo").submit() I expect the thing to submit. $("#foo")[0].submit() does the same, but from a learning standpoint the need to exit the jQuery object and call the submit() function on the DOM object is confusing. Ease of use should be paramount, and instinctively people think .submit() would submit the form.

.submit() triggers the submit. .submit(function() {}); overwrites it.

That makes the most sense to me at least.

comment:11 Changed 14 years ago by klaus.hartl@…

Such a behaviour would be an absolute showstopper to me and I would consider that as a bug.

Obviously there would be no way of stopping a form to submit if I want to just trigger a validate function or an XHR submit that is typically attached to the submit event handler of a form.

comment:12 Changed 14 years ago by Dave

Alex, if we remove .submit() as a method, people will quickly realize their mistake and use [0].submit() instead. I would say the problem is that the jQuery object has a .submit() method that doesn't do the "obvious" thing, and an easy fix is to remove the .submit() method as expected in jQuery 1.1 rather than trying to define the semantics.

comment:13 Changed 14 years ago by joern

Resolution: fixed
Status: newclosed

Wheather the current submit() method is removed in 1.1 or not is another issue, but the issues described here work just fine as it is.

I improved the documentation for submit(Function) and submit(), reflecting the actual behaviour.

Note: See TracTickets for help on using tickets.