I don't think speed has anything to do with it at all. Are you _sure_
an error isn't happening, preventing the return false? Have you tried
using Event.stop instead? (I realize Rails is generating some of this;
if you can't override the Rails stuff, you probably want to post to a
Rails forum instead.)

Bottom line is that if you really do stop the submit event, it will
not happen. Something is preventing the submit event from being

T.J. Crowder
Independent Software Consultant
tj / crowder software / com

On Aug 5, 7:16 pm, "reuben.m" <reube...@gmail.com> wrote:
> Also, I was thinking this might be because the "return false" was not
> coming quick enough to stop the standard form action. If I call it
> synchronously, will it prevent the default action from being processed
> until the javascript call completes?
> On Aug 5, 12:49 pm, "reuben.m" <reube...@gmail.com> wrote:
> > Ok, I posted a thread a week or two ago about how I was having random
> > and hard to reproduce problems with Ajax.Updater where the response
> > would be to a standard post request rather than an XHR request. The
> > full page returned would get stuck in the innerHTML and everything
> > would fall apart.
> > So I've finally been able to figure a bit more out on what is
> > happening.
> > First, the form request is generated by rails, which creates a
> > javascript based response, and then the standard response to function
> > as a fallback for browsers with disabled javascript functionality.
> > The problem appears to be that every once in a while BOTH are called
> > at nearly the same time. In firebugs console I can see an XHR post
> > request followed immediately by a standard request, and the response
> > for the standard request is shown as the returned value for both of
> > them. (They both have the exact same ETag in the response headers)
> > I have no idea WHY this is happening. Everything is solid. I fixed the
> > one javascript error I mentioned in the previous post, no javascript
> > errors or warnings are popping up.
> > I guess I can setup the forms by hand so that the fallback action
> > isn't created (it doesn't function correctly as a fallback anyway with
> > the way the innerHTML request is setup) but that is a pain in the
> > butt. Unless rail's  remote_form_for has an option to disable the
> > standard form action and just rely on the "onsubmit" javascript.
> > Has anybody any insight on why the browser would make both requests?
> > Javascript taking too long to respond for instance?

You received this message because you are subscribed to the Google Groups 
"Prototype & script.aculo.us" group.
To post to this group, send email to prototype-scriptacul...@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to