How to reproduce the bug
My setup uses an IIS (Microsoft Internet Information Services) which has SSL enabled and uses a self-signed certificate create from within IIS. There is a directory with the content of this zip archive.. There is basically one simple html page that looks like this:
<html> <head> <script> var counter = 0; </script> <script src="JS/1.js"></script> <script src="JS/2.js"></script> <script src="JS/3.js"></script> <script src="JS/4.js"></script> <script src="JS/5.js"></script> <script src="JS/6.js"></script> <script src="JS/7.js"></script> <script src="JS/8.js"></script> <script src="JS/9.js"></script> <script src="JS/10.js"></script> <script src="JS/11.js"></script> <script src="JS/12.js"></script> <script src="JS/13.js"></script> <script src="JS/14.js"></script> <script src="JS/15.js"></script> <script src="JS/16.js"></script> <script src="JS/17.js"></script> <script src="JS/18.js"></script> <script src="JS/19.js"></script> </head> <body> Hello World! <script> document.write(counter); </script> </body> </html>
How to see the bug in Safari
Open the web page in Safari (on iOS 11) by entering the correct url like in my case on the test server in my local network “https://10.50.75.208/test”. The first time you will be asked by Safari to allow opening this site that does not have a trusted certificate. Confirm that.
When the page was opened and correctly shows the expected result, close Safari by showing the list of running apps on the iOS device and swipe away the Safari app. Then open Safari again. Safari will automatically try to open the same page again. In most cases when doing this, the bug will occur and you will see fewer than expected lines with X and lower number than 19 at the end.
Waiting some time and refreshing the page will then always produce the correct result until you restart Safari again.
This video shows the described behaviour on an iPad.
What the developer tools see
When using the Safari developer tools on a Mac connected to the iOS device, we can see what goes wrong:
Speculation: What’s the bug?
My speculation as to what is happening in Safari internally is the following: When Safari starts, it will try to load the list of accepted untrusted ssl certificates in a background task. For some reason, accessing this list and loading this list is not correctly synchronized so that during a short period after starting Safari, a check will be made against the list although is has not been fully loaded and the loading of some referrenced resources will then fail because the untrusted certificate used is not found in the incompletely loaded list..
The only solution to this problem I have found is to not use a self-signed certificate. You need to actually create your own local CA (Certiciate Authority), install this CA’s public certificate on the iPad, manually enable that it is trusted as a CA, then use this CA to create an SSL certificate and then install and use this SSL certificate in IIS (or some other webserver software)