Safari on Mac is close to unusable

Most of the time javascript buttons get stuck on loading without any action. All works fine in latest Chrome (really need safari though)


1 Like

Thanks for getting in touch and I’m sorry you’re having trouble in Safari. We’ll look into this and see if we can reproduce the problems in Safari and fix them. In the meantime, I’d suggest using Chrome or Firefox, as those browsers are used by members of our own dev team, and so get far more testing/use than Safari (even though the whole team uses Macs).

After much investigation, we believe this is a bug with Safari itself (and it wouldn’t be the first that we’ve seen).

We listen to the click event on the button, switch the button to a spinner and “mark” it such that subsequent clicks on the button don’t re-submit the form (people are so used to double-clicking on the desktop, but this very rarely the correct thing to do in a web browser - often resulting in double rackings, etc).

Most of the time, this process works correctly in Safari (and always works correctly in other browsers we’ve tested). Occasionally, Safari changes the button to the spinner, but just doesn’t submit the form! This, I believe, is what you’re observing.

After a lot of trial and error, it turns out that if we intercept the click event, “mark” the form to prevent multiple submissions, then after the form is submitting, apply the spinner to the button, it seems to work properly in our tests. This also (as you’d expect) works in other web browsers. Unfortunately, Safari fails to render the spinner at all, but this is purely visual feedback for you. We’ve deployed this change now and so it would be great if you could let us know if this seems to have fixed it for you too?

This, we hope, will make Safari more usable, but for a better experience (e.g. spinners and better general web compatibility), give Chrome (or Firefox) a go :smile:

Purely out of interest - why?

Hi Luke,

Thanks for that. For the entire ecosystem of apps and integrations. It’s not that we absolutely need it, it’s just really annoying when you working and then for one web admin you have to switch to a whole new browser that doesn’t share your passwords etc. Also switching between browsers gets annoying when you forget you have to use breww for products and racking in Chrome already have some stuff open in Safari (your default browser).

The one thing that strikes me is that like you saying a form is not being submitted. I indeed couldn’t see the loading of a page in the url/progress bar. Redirects and form submission is the most basic js functionality in any browser so I would assume this would more likely be incorrect implementation instead of a browser bug.

Either way, Apple is surprisingly responsive to reported bugs on any of their apps (I used to work for them and the triage is absolutely best) so I would suggest filing a radar ticket with them if you believe this is truly a bug in Safari.

Thanks for looking into this.


Thanks, yes, that makes sense.

I agree that it’s surprising! We’re not actually submitting the form using javascript; we’re just intercepting the click to set a variable to prevent multiple submissions and adding a spinner. Then, we simply don’t prevent the default action of the click and let the browser submit the form (as is the normal action of a submit button). Most of the time, this submits the form, but sometimes it just doesn’t :exploding_head:

Seemingly, if we continue to set the variable to prevent double submission in the button click handler but delay showing the spinner icon for 50ms using a setTimeout(...), Safari always submits the form (or at least failing to submit becomes so rare that we couldn’t make it fail), even though it doesn’t actually show the spinner.

We truly believe so! I’ll look to create a simple test case and get a bug filed :+1:

I appreciate this is getting technical, but for you and anyone else interested (I may end up sending this to Apple, or another dev Googling this in the future)…

This is the seemingly working code:

const wizard_form = $('#wizard_form');

$('button[type="submit"]').on("click", function (e) {
    // Handle single submission
    if ("submitting") === "true") {
        // Catch the double click and prevent submission
        return false;
    } else {
        // Abort if not valid (and we need to validate)
        if ($(this).attr("formnovalidate") === undefined && wizard_form[0].checkValidity() === false) {
            // Don't prevent default, let the browser show the validation errors
            return false;

        // Add data to catch next time"submitting", "true");

        // Make the UI changes, see
        let button_clicked = $(this);

            button_clicked.html("<i class='far fa-spinner fa-spin'></i>");
            $(".refresh-input").val($(this).attr("id") === "button-wizard-refresh");
        }, 50);

        return true;

However, if the section:

    button_clicked.html("<i class='far fa-spinner fa-spin'></i>");
    $(".refresh-input").val($(this).attr("id") === "button-wizard-refresh");
}, 50);

Is replaced with just the following (there’s no setTimeout):

button_clicked.html("<i class='far fa-spinner fa-spin'></i>");
$(".refresh-input").val($(this).attr("id") === "button-wizard-refresh");

Then Safari sometimes doesn’t submit the form, whereas Chrome and Firefox always still submit the form. Safari also doesn’t actually render the spinner, even though the code does run (as adding a console.log(...) in the setTimeout(...) will be shown in the console). And we’ve verified that those two lines of code don’t trigger an error that’s causing the problem.

Usually, when a dev comes to me and says, “It’s not our bug! It’s a bug in [something used by far, far, far more people than our own code],” I don’t believe them… but this does look like it. :joy:

Got it, potentially changing the approach from bottoms up could be considered. Instead of intercepting the click, the form could get submitted as is on click of a regular button and then disabled. The benefit of that approach would be the the most important action, the data submission happens, button can be then disabled as a part of the action. If that makes any sense …

It makes sense, but unfortunately (as far as I’m aware), javascript doesn’t have an after-form-submission (or similar) event, so our only option is to get involved before submission.

Either way, it still looks like a bug in Safari. We hoped the days of IE6 were in the past, but Safari is forever nostalgic for the good old days of building everything multiple times over for each browser :joy:

Hopefully, the recent changes have done the trick (in which case; if it ain’t broke, don’t fix it). But if you still have trouble using Safari, do let me know, as we do intend to support it :+1:

Thanks for bringing this to our attention - we were unaware of the problem before.

“We’re not actually submitting the form using javascript”
But if you did? i.e. via XMLHttpRequest or whatever the kidz do nowadays.

1 Like

Thats what I was thinking about just was a lazy bum to test it lol

Sure, we could reinvent the wheel, but web browsers should be able to reliably submit forms.

In all honestly, we’ve no desire to re-write form submissions for one buggy web browser that we’ve already got a good workaround for. We have a long list of feature requests that I’m sure our customers would rather we were working on :wink: