Skip to main content

Bug Tracker

Side navigation

#134 closed enhancement (fixed)

Opened August 23, 2006 04:48AM UTC

Closed December 11, 2006 09:37AM UTC

Last modified July 23, 2009 12:28PM UTC

Trigger browser event

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

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

For example:

$(foo).click()

would also trigger:

foo.click()

(if it exists)

Attachments (0)
Change History (13)

Changed August 31, 2006 06:25AM UTC by john comment:1

priority: majorminor
type: bugfeature

Changed October 06, 2006 02:56PM UTC by joern comment:2

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

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

Changed November 17, 2006 10:25PM UTC by john comment:3

description: Adding: .submit(), .reset(), .getAttribute(), .setAttribute(), .removeAttribute() would save a lot of... hassle.If you trigger an event $(...).submit(), .focus(), .blur(), .select(), .click(), etc. It should trigger the DOM Element's internal event function.\ \ For example:\ $(foo).click()\ would also trigger:\ foo.click()\ (if it exists)
priority: minormajor
summary: Some DOM methodsTrigger browser event
type: featureenhancement

Changed November 17, 2006 10:25PM UTC by john comment:4

component: coreevent
milestone: → 1.1
version: → 1.1

Changed November 21, 2006 01:55PM UTC by joern comment:5

What happens when calling this?

$('#myform').trigger('submit');

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.

Changed November 24, 2006 03:43PM UTC by sam comment:6

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:

$("#foo").submit()

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.

Changed November 29, 2006 09:38PM UTC by Dave comment:7

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.

Changed November 29, 2006 11:10PM UTC by blair comment:8

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.

Changed November 30, 2006 12:58AM UTC by anonymous comment:9

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.

Changed November 30, 2006 05:15PM UTC by Alex Cook comment:10

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.

Changed December 01, 2006 08:08AM UTC by klaus.hartl@ comment:11

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.

Changed December 06, 2006 10:40PM UTC by Dave comment:12

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.

Changed December 11, 2006 09:37AM UTC by joern comment:13

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.