“alert()” and “confirm()” not working with “apple-mobile-web-app-capable”

Under iOS (currently 7.0), it looks like alert() and confirm() are not working when our web app is pinned to the home screen (aka using the meta tag apple-mobile-web-app-capable).

I found a user having a similar issue on twitter:


Anybody has a temporary fix if it’s really a bug in iOS 7?

We had a similar issue with alerts breaking our web app. The specific case was an alert which was triggered from the onchange of a select list. We put together a very simple test page like this:

<!DOCTYPE html>
        <meta charset="utf-8">
        <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
        <meta name="description" content="">
        <meta name="viewport" content="width=device-width">
        <select onchange="alert('broken!');">
            <option value="one">One</option>
            <option value="two">Two</option>

Running that page from Safari in an iPad and changing the select list triggers the alert then Safari freezes. You actually have to then close Safari. This affects Safari in general – your web app doesn’t have to be pinned to the home screen. You should be able to test this on an iPad running iOS 7 on this test page http://jsbin.com/AGoTejA/1.

We have tested this on an iPad 2 (MC774B/A) and an iPad 3 (MD367B/A) and Safari crashes on both.

A hacky way to get around this is to use a setTimeout() to delay execution of the alert. The problem only seems to happen when Safari is trying to display the overlay which shows the select list items and an alert at the same time. confirm() is also broken in the same way.

I don’t know if it is by design or a bug but I can confirm this is a real problem. One other thing to be aware of is that if the user has the option to save passwords enabled, any site that requires a login will fail because that prompt is also blocked. (you can try this with a simple form with a username and password box and nothing else and it simply won’t submit). There are workarounds though for all three issues.

  1. Login – set autocomplete=”off” in the form tag for the site, or detect that the site is running IOS7 and in fullscreen mode and apply this setting

    $('form').attr('autocomplete', 'off');
  2. Alerts and Confirms – you can either write a custom function in JavaScript or override the existing functions in much the same way as here: http://andrewensley.com/2012/07/override-alert-with-jquery-ui-dialog/. I like using Eric Martin’s SimpleModal plugin which has a built in Confirm override, the bottom demo on http://www.ericmmartin.com/projects/simplemodal-demos/.

I hope some of that helps.

I solved with a setTimeout

<select onchange="setTimeout(function(){alert('not broken!');},200)">
                <option value="one">One</option>
                <option value="two">Two</option>


Anyway, seems this bug afflicts the iPad and not the iPhone.

I had this happening for me with the following code:

const confirmation = window.confirm(message || 'Are you sure?');

The confirm would show up on PC (Edge browser), but not on iPhone (Safari browser)

I changed the code to the following (removed the window.):

const confirmation = confirm(message || 'Are you sure?');

And suddenly it was working again.

Read More:   Is parsing JSON faster than parsing XML

I am guessing that Apple got its own implementation of confirm that does not need the window.

I think that a bug related to the smooth hiding selection boxes animation.
I do not like hacks, but this method works.
Confirming called after 100 ms (this is enough for the time until the selection window closes)

var object;

$('form select').change(function()
    object = $(this);
    timer = setTimeout(confirmation, 100);

function confirmation()
        case 'post_approved':
        case 'post_delete':
        case 'thread_delete': object.parent('form').find('input[name=id]').val(object.parent('form').find('input[name=post_id]').val()); break;
        case 'user_delete_all': object.parent('form').find('input[name=id]').val(object.parent('form').find('input[name=user_id]').val()); break;
        default: return false; break;

    if(object.parent('form').find('input[name=act]').val() === 'post_approved'  || (object.parent('form').find('input[name=act]').val() != '' && confirm('Вы уверены?')))
        return false;

Andersen is correct:

javascript alert() and confirm() bugs fixed as of iOS7.0.3

just installed and tested it myself.

While Apple was fixing the issue, I scrambled to find something to work around it, and ended up finding a js plugin called Alertify that I thought this was worthwhile to share. I think I’ll use it from now on, regardless of the bug fix! It just makes alerts, prompts etc look really, really good. Thought it was worth sharing since readers of this post are likely using the standard browser alerts. I was stoked to stumble across it.

I noticed this today on iOS 16 – which will be released publicly in a few days. It quite likely was happening on previous versions-I just didn’t notice.

I had some debugging alerts that would show when I click certain buttons. They were working correctly until I navigated back using the swipe motion. After that all the logic surrounding the alert was occurring correctly, but the dialog box didn’t show.

Read More:   Determine if point is within bounding box

And no it wasn’t reloading a previous version of the site as everything else was as expected.

If this is by design, I can’t imagine why.

The answers/resolutions are collected from stackoverflow, are licensed under cc by-sa 2.5 , cc by-sa 3.0 and cc by-sa 4.0 .

Similar Posts