Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

disable_with doesn't work with link in Safari #306

Open
pekeler opened this Issue · 48 comments
@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..."

@pekeler pekeler referenced this issue in rails/jquery-rails
Closed

disable_with doesn't work with link in IE #82

@JangoSteve
Collaborator

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.

@pekeler

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

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

@JangoSteve
Collaborator

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

@neerajdotname
Collaborator

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

@pekeler

I've created a minimal testcase on http://jsbin.com/aveseh/1/

@neerajdotname
Collaborator
@pekeler

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

@travis

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.

@eploko

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.

@pzgz

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

@xaviershay

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

@xaviershay xaviershay referenced this issue in plataformatec/simple_form
Closed

:disable_with option is not working #640

@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

@barkerja

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

@lucasmazza
Collaborator

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

@JangoSteve
Collaborator

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

@uberllama

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

@jalendra-webonise

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

@joker-777

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

@uberllama

In my test cases, the disabling functionality was totally borked. No state change, no text change.

@jbmyid

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.

@joker-777

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

@jbmyid

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

@uberllama

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

@lucasmazza
Collaborator

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.

@uberllama

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.

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

@iqbalhasnan

+1 not working with Safari Version 7.0.2 (9537.74.9)

@alecguintu

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.

@pekeler

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

@alecguintu

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

@martijnrusschen

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

@nabeta nabeta referenced this issue in next-l/enju_leaf
Closed

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

@debajit

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.

@geetfun

disable_with works on Safari 8.0.2 for me

@pekeler

@geetfun not for me

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

@velobuff

<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 :/

@elsurudo

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.

@amal007

any idea how to fix this in Safari.

@ericboehs

This is simply a display problem in Safari. If you try clicking the submit button twice it doesn't submit twice. To verify this, inspect the element and then click the submit button, you'll see the HTML change (value is replaced and disabled attribute is added).

Safari doesn't update the displayed page after the form submit is fired (even though the DOM changed). If we wanted to fix this visual bug we'd need to intercept the submit event, update the DOM, then submit the form ourself (carefully though as we don't want to double submit). See http://stackoverflow.com/a/28404683/282720

I think the main desire of this feature is to prevent double form submission and that is working correctly. Perhaps this should be closed in favor of a radar bug submitted to Apple.

Edit: Just noticed this is regarding link_to and not form submit. I can't reproduce @pekeler's problem in Safari 8 unless I use a form submit button.

@edgarjs

Using Safari 8.0.4 (10600.4.10.7) still doesn't work (in some cases). I tried the test pages from this thread and also created one myself, disable works in all those cases but still doesn't on my real form.

I removed all other javascript from my app and just left jquery and ujs files, but no luck. Then I went and debugged a little bit and if I remove the timeout from this line it works perfectly.

It seems like a UI blocking issue to me, once the timeout has returned the form is already submitting and safari doesn't care anymore to update it. But if we update it just before it submits, it does it correctly.

Not sure what the timeout is for though? Comments say it's for the button to be serialized, but why do we need the button serialized? (Some may need it of course, but most forms don't). Would it be possible to add a setting for letting the timeout or remove it?

@rapcal

I have a similar issue on Safari with a submit_tag with an :onclick to show an overlay. It doesn't work either, which seems to confirm the display problem mentioned by @ericboehs

@rapcal

By the way - and that's even worse usability-wise - when you hit the back button the overlay is there... IMHO this issue should be closed since it doesn't seem to be jquery-ujs specific

@lyushenko

I had a similar issue on Safari 8.0.6 and here's my approach of solving this issue:

%button{ class: 'btn btn-action js-submit', data: { method: :put, 'href' => '...', disable_with: "<i class='icon icon-spinner icon-spin'></i>".html_safe }} Submit
$('.js-select-plan').click(function(event) {
  event.preventDefault();
  var $target     = $(this),
      href        = $target.data('href'),
      method      = $target.data('method'),
      formTarget  = $target.attr('target'),
      csrfToken   = $('meta[name=csrf-token]').attr('content'),
      csrfParam   = $('meta[name=csrf-param]').attr('content'),
      form        = $('<form method="post" action="' + href + '"></form>'),
      metaData    = '<input name="_method" value="' + method + '" type="hidden" />';

  if (csrfParam !== undefined && csrfToken !== undefined) {
    metaData += '<input name="' + csrfParam + '" value="' + csrfToken + '" type="hidden" />';
  }

  if (formTarget) {
    form.attr('target', formTarget);
  }

  // disable button/link element
  var contentMethod = $target.is('button') ? 'html' : 'val';
  var replacement   = $target.data('disable-with');
  $target.data('ujs:enable-with', $target[contentMethod]());
  if (replacement !== undefined) {
    $target[contentMethod](replacement);
  }
  $target.prop('disabled', true);

  form.hide().append(metaData).appendTo('body');
  setTimeout(function(){
    form.submit();
  }, 50);
});

This works like a charm in all browsers. For better flexibility you might want to wrap this in a helper.

@kelso

Still doesn't work in Safari 9.0 (El Capitan). Firefox + Chrome are OK.

@thiensubs

Yes. It isn't working with safari in ipad or iphone. :(

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.