Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


disable_with doesn't work with link in Safari #306

pekeler opened this Issue · 40 comments

22 participants

Christian Pekeler Steve Schwartz Neeraj Singh Travis Vachon Andrey Subbotin Leon Guan Xavier Shay John Barker Lucas Mazza Yuval Kordov jalendra-webonise joker-777 jbmyid Iqbal Hasnan Alec Guintu Martijn Russchen Debajit Adhikary geetfun Raman Sinha Ernest Surudo Mike Ball Amal
Christian Pekeler

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..."

Christian Pekeler pekeler referenced this issue in rails/jquery-rails

disable_with doesn't work with link in IE #82

Steve Schwartz

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.

Christian Pekeler

My version of Safari seems to be different: Version 6.0.2 (8536.26.17)
this is on OSX 10.8.2

Christian Pekeler

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.

Steve Schwartz

That's really weird. I'll have to see if I can get anyone else in the office who can reproduce it.

Neeraj Singh

@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.

Christian Pekeler

I've created a minimal testcase on

Neeraj Singh
Christian Pekeler

I just walked over to another computer with Mountain Lion, Safari 6.0.2. Exact same problem.

Travis Vachon

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) {
      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.

Andrey Subbotin

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.

Leon Guan

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)"

Xavier Shay

Can reproduce on Safari 6.0.5 (8536.30.1), OSX 10.8.4.

Xavier Shay xaviershay referenced this issue in plataformatec/simple_form

:disable_with option is not working #640

Christian Pekeler

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

John Barker

Add Safari Version 7.0 (9537.71) (Mavericks GM) to the list of not working either.

Lucas Mazza

@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

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:

Steve Schwartz

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).

Yuval Kordov

+1 to this not working with Safari 7.0 (9537.71).


+1 doesn't work with safari. checked with 7.0


Hi, short question...
Is also the disabling functionality broken or only the display of the disable text?

Yuval Kordov

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.


Does it only break with a form submit field or also with a normal link?


I haven't checked it for link but its breaking for submit field.

Yuval Kordov

Any progress on this issue, guys? It's a big one.

Lucas Mazza

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.

Yuval Kordov

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.

Christian Pekeler

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.

Iqbal Hasnan

+1 not working with Safari Version 7.0.2 (9537.74.9)

Alec Guintu

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.

Christian Pekeler

@alecguintu this bug is just about the display issue you're seeing.

Alec Guintu

@pekeler A so it's a different one than the original post? Is there a post on this already I can check?

Martijn Russchen

Is someone working on this? Having the same issue and cannot find a working solution for it...

Kosuke Tanabe nabeta referenced this issue in next-l/enju_leaf

「所蔵を作成」ボタンが連打対策 #41

Debajit Adhikary

The problem still exists in Safari 7. using

submit_tag "title", data: { disable_with: "disabled text" }

does not work in Safari either. Please let me know how I could fix this.


disable_with works on Safari 8.0.2 for me

Christian Pekeler

@geetfun not for me

Safari 8.0.2 broken
FF 34.0.5 works
Chrome 39 broken
IE 11 broken

Raman Sinha

<button class="btn btn-default" data-disable-with="<i class='fa fa-spinner fa-spin'></i> Saving..." name="button" type="submit">Save Post</button>
On OSX 10.9.5 Build 13F34:
Safari Version 7.1.2 (9537.85.11.5) :broken_heart:
Chrome Version 39.0.2171.95 (64-bit) :heart:

If you press Submit and then hit the :back: button in Safari, the button now appears the way it would if disable-with worked (it's disabled and has the disable-with html)!

I tried removing turbolinks but that made no difference :/

Ernest Surudo

Also having this issue.

OS X 10.10.2
Safari 8.0.3

Anyone got a decent workaround?

Mike Ball

I have the same issue. data-disable-with works find in Chrome, but not in Safari.

OS X 10.10.2 (14C109)
Safari 8.0.3 (10600.3.18)

It's really frustrating, since I prefer to develop locally using Safari.


any idea how to fix this in Safari.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.