I have just upgraded my iOS because of the recent security bug, and I find that my website is no longer loading properly on my phone!
I've boiled the problem down to a simplified example...
index.html =
<html>
<head>
<title>Demo</title>
<meta name="description" content="Test of basic Javascipt function">
<script src="demo.js"></script>
</head>
<body class="body">
<div id="main">
</div>
</body>
</html>
demo.js =
var i = 0;
function update() {
'use strict';
document.getElementById("main").innerHTML = i;
i = i + 1;
}
setInterval(update, 1000);
On my desktop this produces an iterating count, but when viewed with Safari on my phone (Mobile/12G34 Safari/601.1) the javascript file simply does not load???? The Javascript file doesn't even show up under the "All Resources" tab in my WebInspector which I am tethering via USB.
Suggestions?
Thanks,
Bill
Edit:
This question has gotten no response, but I'm still wrestling with this problem. I've found some more information.
Using the Safari WebInspector I've found that the javascript is not loading because...
Blocked script execution in 'http://192.168.133.1/demo.html' because
the document's frame is sandboxed and the 'allow-scripts' permission
is not set.
Since I'm serving this page off a homespun webserver on an esp8266, this message has inspired me to tune up my HTTP headers. The HTTP headers appear to be fine.
I can't figure out how this html page is getting sandboxed in the first place, and how to 'allow-scripts' so that I can run my script in Safari Mobile.
Any help would be much appreciated.
I had exactly same issue when implementing web server functionality for my Arduino project. My web server implementation worked fine with desktop browsers and with Chrome in iOS (9.3.5). I had problems both with Firefox (5.1 (1)) and Safari in iOS. My web pages use scripts including jQuery. Scripts are used for transferring data from Arduino with AJAX/JSON.
The problem was in the examples I used as a basis for my implementation. In those examples, web server's reply to browser's HTTP GET request in OK case doesn't contain anything else than the actual document requested. In that case web browser thinks that the web server is using HTTP/0.9. In addition, Content-Type is missing. Most of the browsers can "guess" what is the Content-Type of the reply although it is not included.
In my case, Safari reported two errors
- Blocked script execution in http://myip because the document's
frame is sandboxed and the 'allow-scripts' permission is not set.
- Sandboxing http://myip/image.jpg' because it is using HTTP/0.9.
The first error causes browser to refuse loading my javascript and also jquery.js. Of course after that AJAX won't work. Firefox in desktop also nagged about not well-formed JSON replies but still worked fine.
I simply changed the implementation so that HTTP replies will always include HTTP version, status code and Content-Type before the actual data. For example, when browser sends request GET / HTTP/1.1, the server doesn't just send the default web page but includes
HTTP/1.1 200 OK
Content-Type: text/html
After that all errors disappeared. It seems new versions of Safari don't like to receive HTTP/0.9 and will sandbox what it gets back.
Had the same issue (iOS 9.3.3 Safair/Chrome and on OSX with Safari 9.1.2).
The reason was that we used a javascript library to try to load retina versions of all our images. Somehow the request sent using HTTP/0.9 and not HTTP/1.1 which made Safari automatically sandbox the whole page on all following requests (the error message said something like "automatically sandboxed ... because of HTTP/0.9"). The security changelog of iOS 9.3.3 (https://support.apple.com/en-us/HT206902) mentions something related under CVE-2016-4651.
Make sure your web server supports HTTP/1.1 and that you request the page using HTTP/1.1
