Well, I'm not 100% sure, but then again, it's only two calls, the Ajax.Updater, followed by return false. If something is going wrong, it's within Ajax.Updater.
Forgive me, but I'm not much of a Javascript wiz. I've not used the Event.observe stuff before, does it set up polling of some sort, or does it register a callback somewhere? Or for that matter do I even need to set up an Event.observe? Can the Event.stop be called just before Ajax.Updater? I appreciate the help. -Reuben On Aug 5, 4:41 pm, "T.J. Crowder" <[email protected]> wrote: > 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 / comwww.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.
