On Jul 18, 2:29 am, Stephan Beal <[EMAIL PROTECTED]> wrote: > Does disabling the element for 500ms sound like a reasonable solution > to you? i'm not sure that disable makes much sense for non-buttons, > but i think that buttons will make up 90%+ of use cases. > > ???
A bit of follow-up: i've added code to implement a "disabling delay", but: a) disabled=true only works for some elements (e.g. BUTTONS), so this isn't usable when the click-zone is a different element. This could be made to work by shuffling the click() handlers around and changing the element's class (for visual disable effect), but i haven't gotten that far along yet, and probably won't because... b) i'm getting weird behaviours vis-a-vis cancellation/confirmation when i quickly double-click. When quickly double-clicking, sometimes a confirmation takes and sometimes it doesn't. i believe this has to do with a second click getting through (or queued) before the disabled=true has a chance to happen (classic race condition). So the "briefly disable" behaviour is not reliable enough for "production use", IMO. Bummer. i think i'll just punt on this perceived problem for the moment and say, "if you're stupid enough to double-click a form element, and thereby risk POSTing data twice, then you deserve any bugs you get." :- P But i will keep the problem in mind and search for a graceful solution. i just won't spend too much time hacking on it until a good idea comes around. Thanks once again to all of you for your feedback so far. :D Happy hacking!
