Hi,

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
stopped.

FWIW,
--
T.J. Crowder
Independent Software Consultant
tj / crowder software / com
www.crowdersoftware.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 
prototype-scriptaculous+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/prototype-scriptaculous?hl=en.

Reply via email to