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" <[email protected]> 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" <[email protected]> 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en.
