If you bind the editable "on the fly" as the click occurs - Some browsers have concurrency issues.
Interestingly enough a similar issue occurs with Jquery Autocomplete Plugin - but this issue is caused by the fact the author used a setTimeout() in the initialization of the plugin - I'm not sure if jeditable has any setTimeout() statements in its source but you might want to do a search. In general when a page redirects its because the browser handled an elements event in a default fashion meaning the code wasn't 'ready' or wasn't 'available' to execute - or you need to "return false" or stop event propagation somewhere. I know in safari if you bind a click handler to an <a> element and then in the body of that handler you simply return false (stopping the browser from following the anchors link) - if you click quickly enough in safari the events will "que" up, once the que is full or the browser is too busy the default event / action will occur, your code won't run, and the page will redirect. You might want to begin managing the event que as well using jquery - you can cancel que events when the que buffer becomes too large. I've had to implement this functionality with complex animated menus before, to make sure too many animations don't get 'stacked up'. On Dec 2, 12:06 pm, "[email protected]" <[email protected]> wrote: > An update to my original e-mail: I have ascertained that the behaviour > is exhibited only in WebKit browsers. IE and Firefox are fine, but > Chrome and Safari don't work.
