jquery-ujs
jquery-ujs copied to clipboard
rails
disable_with doesn't work with link in Safari
link_to "do it", :data => {:disable_with => 'Please wait...'} Please note that this is not a remote link.
It works as expected in latest Chrome and latest Firefox, IE8, IE9. In Safari (6.0.2) however it never shows "Please wait..."
testpage: https://gist.github.com/pekeler/4746738 (rendered without layout) result: http://youtu.be/kwCWrvhQJ2c
I cannot reproduce this to save my life. I've tried on my own machine using Safari Version 6.0.2 (7536.26.17), and it works as expected.
My version of Safari seems to be different: Version 6.0.2 (8536.26.17) this is on OSX 10.8.2
My wife's laptop has the same Safari version as yours on OSX 10.7.5. I can't reproduce it there, either. So it looks like a Safari on Mountain Lion specific problem.
That's really weird. I'll have to see if I can get anyone else in the office who can reproduce it.
@pekeler if you can push this code to heroku and post a link here then that would make it easier to get more people to validate the result. Thanks.
With safari version Version 6.0.2 (8536.26.17) it behaves fine for me .
On Tue, Feb 19, 2013 at 12:41 PM, Christian Pekeler < [email protected]> wrote:
I've created a minimal testcase on http://jsbin.com/aveseh/1/
— Reply to this email directly or view it on GitHubhttps://github.com/rails/jquery-ujs/issues/306#issuecomment-13786179.
I just walked over to another computer with Mountain Lion, Safari 6.0.2. Exact same problem.
FWIW we noticed an issue with disabled_with on Safari, but with an <input type=submit. The submit button on a form won't change when we click the submit input. What's really insane is that if we do this:
disableFormElements: function(form) {
alert('hams')
form.find(rails.disableSelector).each(function() {
and then click through the alert dialog, the button changes disabled text. Also, if we cancel the next page load before the screen changes, the button changes to the disable text. So this seems like a pretty classic example of javascript timing insanity. Frankly, the prospect of descending into the caves of madness to debug this is too much for us right now, and we iceboxed the issue.
Hopefully this helps point someone in the right direction.
Have just stumbled upon this exact issue. :( Mountain Lion 10.8.3, Safari 6.0.3 (8536.28.10). Works fine in Chrome. Any suggestions if not for a fix then for a workaround would be greatly appreciated.
Same problem here, the text doesn't get changed by text in 'disable-with' on safari, worked fine on chrome. I am using safari "Version 6.1 (8537.43.58)"
Yup, still broken in Safari 6.0.5 (8536.30.1) now also broken in Chrome 29.0.1547.57 and broken in IE 10
still working in Firefox 23.0.1
Add Safari Version 7.0 (9537.71) (Mavericks GM) to the list of not working either.
@pekeler your test case on jsbin isn't working for me as pulling the rails.js from GitHub does not provides the right mime type, so I rewrote it and tested on Safari Version 6.1 (8537.71) and Chrome Version 30.0.1599.101 under OSX 10.8.5. My test is here https://dl.dropboxusercontent.com/u/3258720/jquery-ujs-306/index.html
Are anyone else still facing this issue with a recent version of the jquery-ujs code? Other test cases that are doing something else that we are missing would be very helpful to finish this long running issue once in for all :smile:
I'm guessing this is still an issue, as we've never done anything to solve it. If someone could submit a patch, that'd be great. I'd be happy with a patch that solved the issue even without a test case (provided it doesn't break any existing tests).
Hi, short question... Is also the disabling functionality broken or only the display of the disable text?
In my test cases, the disabling functionality was totally borked. No state change, no text change.
Actually Safari is not allowing to manipulate the form element (submit tag) after form submit. Tried first change the text and then submit but then the commit can not be accessed.
I still can't reproduce this with Safari 7.0.1 (9537.73.11). Would be awesome to have a reproducible test case or example somewhere to try to get to the bottom or this.
I'm running the exact same version of Safari and it doesn't work at all, nor does it work anymore with Chrome. I'll try and find the time to put together a sample heroku app for you to test against, but I can't imagine why your experience would be different.
Essentially, what jquery-ujs does is:
$('a').on('click', function() {
$(this).html("disable msg");
});
Which doesn't work in the latest Safari, Chrome, or FF. And why should it? The user clicked on a link to navigate to a new location and probably doesn't care about further DOM changes on the old page, so why bother slowing things down by repainting the old page (is what I'd be thinking if I was a browser developer).
This works:
$('a').on('click', function() {
var destination = $(this).attr('href');
$(this).html("disable msg");
setTimeout(function() {location = destination;}, 0);
return false;
});
I.e. we cancel the click, update the DOM, and only then navigate to the new location. A problem with this is that the disable message is still there when going back with the browser's back-button. And there may be other click-handlers which won't be executed anymore.
Weird though, it does kinda work in Safari 6.1.2 (7537.74.9)- the form/link can only be submitted once but the display doesn't change. Actually sometimes it does change and writes the value inside the disable_with but sometimes it doesn't as well but any of them doesn't apply the "disable" property on the buttons/links so it is always clickable but the form/link only submits once.
