Using the current version of the Safari browser (7.0.x) on the current version of OS X (10.9.x), the Hide blocking method does not work well: Submitting a form the first time usually works OK (the specified Processing text is displayed). However all subsequent submissions of that form will no longer display the Processing text.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Chipie’s picture

Is there a solution/workaround for safari?

crabsoul’s picture

I tried using this in css and it worked for safari
.hide-submit-disable { display: none !important; }

greggles’s picture

Version: 7.x-2.0 » 7.x-2.x-dev
Status: Active » Postponed (maintainer needs more info)

Is this still a problem with the latest versions of the module? I know the css/html has changed a bit.

ptmkenny’s picture

Status: Postponed (maintainer needs more info) » Active

I can confirm that with El Capitan (10.11.4) with the stock Safari (as of May 2016, the latest version of OS X), the "hide submit" does not work using the latest version of this module.

The button is hidden properly in Chrome and Firefox.

hkovacs’s picture

I wonder if this is similar to the ie 'bug':
i found this interesting snippet re ie failure (http://stackoverflow.com/a/780617):
"IE assumes that the clicking of a link heralds a new navigation where the current page contents will be replaced. As part of the process for perparing for that it halts the code that animates the GIFs. I doubt there is anything you can do about it (unless you aren't actually navigating in which case use return false in the onclick event)."

miloshito’s picture

I reported similar issue here : https://www.drupal.org/node/2786377

ptmkenny’s picture

Title: Hide blocking method does not work well in Safari on OS X » Hide blocking method does not work well in Safari

Some more info:

* The CSS in comment #2 does appear to fix the problem (tested on Sierra).

* The problem also occurs in iOS (confirmed on iPad with iOS 10 by one of my users).

greggles’s picture

Status: Active » Needs review
FileSize
357 bytes

Here it is as a patch, at least.

One question/note: if using the ladda library this problem should be gone, right?

vladan.me’s picture

One question/note: if using the ladda library this problem should be gone, right?

No, not really, I've just tested on Safari 10.0.1 loading indicator, it doesn't show up. It has all properties though, looks like a proper ladda element at least.
<button class="form-submit ladda-button button" id="edit-submit" name="op" value="Submit" type="submit" data-style="expand-left" data-spinner-color="#000" data-spinner-lines="12"><span class="ladda-label">Submit</span><span class="ladda-spinner"></span></button>

pivica’s picture

Stumble on this bug also. Using ladda lib to show spinner on form submit - everything works nice except in Safari (both desktop and iPhone).

Invested bit of debugging and testing and manage to identify the problem - it seems that on submit event Safari will not redraw UI, meaning all the CSS changes we want to do will not be visible, that is the reason why spinner is there but we can not see it.

Found then next stackoverflow thread http://stackoverflow.com/questions/22043493/unable-to-make-style-changes... - guys have the same problems and offers couple approaches for solution. Based on ideas from this thread i've created a patch that fix stuff for Safari (tested desktop and iPhone 7 version) and also tested Chrome no changes there, works as expected.

Didn't tested other options like hide, just the spinner.

Don't like this solution very much, but seems it fix the Safari problem. If others can test and verify so we at least know that UI redraw on form submit is the problem and not something else?

pivica’s picture

Status: Needs review » Needs work

So scratch previous patch, tested this more in various situation and... Yes it does work in a sense that animation is enabled, Safari is really blocking UI on submit event. But this will mess form submission with multiple submit buttons.

For example node edit page, you hit delete and it will not work because form.submit() is triggering default submit action. And it seems there is no way to make this differently easy if you are using standard form.submit() - and even if its possible its way to complex which make this approach bad.

Conclusion - Safari and it blocking UI rendering on form submit is a problem and i can't figure solution for this currently. As only positive thingy button will get disabled status in Safari so at least duplicated form submission is prevented.