I''m having two different problems with a web application I''ve been working on, but I''m beginning to think they are related and involve a bug in using <code>return false;</code> under prototype managed functions (such as in observe). The first case is with an observer on certain ''links''. The href target is simply "#". Before using prototype I found simply returning false at the end of whatever code I wanted to execute as a result of the click worked fine in both Firefox and IE to prevent ''#'' being appended to the current page''s url. However since adding onclick handlers via $ ().observe and such using prototype, I noticed that returning false no longer seemed to suppress the updating of the pages URL. I''m early in the development stage (I work on Linux and use Firefox as my browser, just occasionally checking the page with IE from a windows system for any erorrs). and that was a minor issue so I ignored it for the moment. The page I am working on has multiple forms on it, and I use prototype and css to manage their presentation and workflow. I had a problem with the behavior of (sub)forms being submitted when the user pressed the Enter key, as it broke our intended workflow (subform submission being done via AJAX), so today I added an Event handler to watch for Enter being pressed within a form. That handler determined the active form and took the appropriate validation/submission actions just as if the user had clicked ''next'' or whatever in our planned workflow. The javascript detects the enter key, calls the expected code and submits via AJAX using the desired function (and its reception is confirmed on the server). <code>return false;</code> is (I thought) the last statement executed after all the updates are made, which, I thought, would suppress the Enter key being otherwise used to submit the form. However, it then goes ahead and submits it a second time, breaking the workflow as before. I have come to believe it is a problem with returning false from a prototype function under Firefox when, after far too much *head->desk* I thought I''d go see what happens under IE. ... And for the first time in ages, everything worked as I expected it under IE while it wasn''t under Firefox! Under IE, not only does enter submit the form and update the pages workflow as planned, it stops there and does not submit the page completely as a second event, apparently respecting the <code>return false;</code>! At that point it occurred to me to check out the URL, and sure enough, the links through the subforms submitted for validation and updated the page as desired, without appending ''#'' to the URL. Is this a known bug? If so is there a patch or a workaround? Is it specific to Firefox 2? Or have I just done something wrong along the way? Thanks, Sean --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Michael Peters
2007-Aug-01 17:49 UTC
Re: Prototype: Problem with return false; in Firefox?
Gilant wrote:> I''m having two different problems with a web application I''ve been > working on, but I''m beginning to think they are related and involve a > bug in using <code>return false;</code> under prototype managed > functions (such as in observe). > > The first case is with an observer on certain ''links''. The href target > is simply "#". Before using prototype I found simply returning false > at the end of whatever code I wanted to execute as a result of the > click worked fine in both Firefox and IE to prevent ''#'' being appended > to the current page''s url. However since adding onclick handlers via $ > ().observe and such using prototype, I noticed that returning false no > longer seemed to suppress the updating of the pages URL.use Event.stop() instead. Check the docs on it''s usage.> Is this a known bug?It''s not a bug it''s just that using observe() is different than assigning a handler straight off. For instance, this is how you stop the other events (or default events) for an onlclick handler using direct assignment or observe() el.onclick = function(...) { // do your thing return false; } el.observe(''click'', function(...) { // do your thing Event.stop(e) } -- Michael Peters Developer Plus Three, LP --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
On Aug 1, 2007, at 11:36 AM, Gilant wrote:> Or have I just done something wrong along the > way?You''ve done something wrong along the way. "return false;" works in browsers under certain conditions for backward compatibility reasons, but isn''t the preferred method of stopping an event. <div onclick="doSomething();return false;">foo</div> <!-- works --> $(''foo'').onclick = function () {return false;} //works Event.observe(''foo'', ''click'', function (evt) {return false;}) // won''t work The reason is under the Event.observe model, you may attach multiple observers to the same element/event (with no guarantee of execution order). It looks like Michael has just beaten me to the punchline, but Event.stop() [1] is what you''re looking for. It handles the cross- browser implementations of the event object (Event.preventDefault() in DOM-compliant browsers, and Event.returnValue in IE). Event.observe(''foo'', ''click'', function (evt) {Event.stop(evt);}) // works TAG 1. http://prototypejs.org/api/event/stop --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
That does indeed seem to do the trick in both cases, and in both browsers. Thanks guys! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Just a question on this for the groups collective brains... If you have multiple observers on the same event/same element, and you call Event.stop() in one, I presume it will stop the rest of the event chain from being executed? So, how could we stop the -default- event, such as the form submission but still allow the rest of the Event chain to execute? The event.stop would have to be in the last handler, and there is no way to determine the order, other than the order which they were added? If someone was using multiple third party libraries, then they may not know the order of the events. Gareth On 8/2/07, Gilant <gilant-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > > That does indeed seem to do the trick in both cases, and in both > browsers. Thanks guys! > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---