Bug 16177 – safari freezes animated gifs on submit

• Status: RESOLVED
• Resolution: WORKSFORME
• Component: Forms

[Colin Copeland]

When submitting a form in Safari with JS, animated gifs freeze up. Sometimes I like to do this after disabling all form elements and having a spinning icon appear on the page to show the user that the request is processing.

I'm testing this with Safari Version 3.0.4 (5523.10).

Works in these browsers:
Firefox 2.0.0.9
Firefox 2.0.0.6
Internet Explorer 6.0370.1830

I haven't tested this in IE7.

[Colin Copeland]

Created attachment 17579 [details]
test html page with javascript and css

[Colin Copeland]

Created attachment 17580 [details]
test gif

[Colin Copeland]

Created attachment 17581 [details]
php script to hang

[David Kilzer (:ddkilzer)]

Interesting.  Confirmed behavior difference to Firefox 2.0.0.9 with a local debug build of WebKit r28072 with Safari 3.0.4 (523.12) on Mac OS X 10.4.11 (8S165).

[Adam Roben (:aroben)]

Created attachment 186663 [details]
Non-form test

Looks like this happens with standard navigations, too, not just form submissions.

[Adam Roben (:aroben)]

Created attachment 186673 [details]
Test using a link instead of a button

Also happens for navigation via links.

[Ar Nage]

I tested today with Safari 8.0.8 (10600.8.9) and Mac OSX 10.10.5, the animated loading GIF still freezes when submitting a form.

Is this bug really pending since 6 years???? Can't believe this....

[julia]

Safari freezes also animations on a form submit+redirect. On our company website we have a notification bar (noty.js) showing the following message: "Please wait while you are redirected", which drops down. On every other browser, the notification appears than the redirect happens. On safari the bottom line of the notification is visible only, the animation freezes half way.
Tested it with Safari version 9.0.1.

Looking forward for a solution for this issue.

[rr4ev]

I find that this bug is still reproducible in 2017. Tested on currently latest Safari versions (iphone, ipad, whatever you choose). The only way to bypass this, is to stop the submission of the form, show the spinner, loader, etc. and submit the form then. And still, it might not work.

Good luck with that.

[Brad]

This happens with CSS animations too. I have a script that adds a class to an element and submits the form. As soon as the form is submitted, only the first frame of the animation is shown, and it is frozen that way while waiting for the next page to load. Other UAs don't have this problem.

[Said Abou-Hallawa]

All the attached tests have the following problems:

1. The wait-spinner element has the wrong url for the background image { background: no-repeat url("wait-black.gif"); }. This is wrong because the test gif was uploaded as an attachment to this bug and can't be accessed by naming it "wait-black.gif".

2. The spinner element is a <span> element whose text is a single <span>&nbsp;</span>. The css for #wait_spinner specifies a size of the spinner to be {32, 32}. The right way to do this is to use a <div> element instead.

3. The css for #wait_spinner specifies its "display: none;". And when the button or the link is clicked, the style of the #wait_spinner is changed from "none" to "block". The right way to do this is to set "visibility: hidden;" and change this to "visible" to show the animated image. "visibility: hidden;" accounts for the element in the layout.

I attached a test case which is working after fixing the background link, using <div> and the css property "visibility".

[Said Abou-Hallawa]

Created attachment 378392 [details]
working test case

[Said Abou-Hallawa]

I opened all the attached test cases in Safari and Chrome and they behave the same way on both of them. I am not sure how the old test cases worked in the past with the wrong background url though.

Given I can't reproduce the bug with any of the attached test cases and I do not see differences between running them on Safari and Chrome, I am going to resolve it "WORKSFORME".