简体   繁体   中英

Resize and OrientationChange events not firing in Safari iOS 13

I am trying to set up a Canvas element which fills the window (specifically a container div which fills the body). Everything works fine on desktop, but for some reason in Safari on iOS (tested on 13.4.1) neither the window.resize nor the window.orientationchange events fire at all.

$(function(){
    resizeCanvas();
});

$(window).on('resize', function(){
    resizeCanvas();
});

$(window).on('orientationchange', function() {
    resizeCanvas();
});

function resizeCanvas()
{

    var canvas = $('#my_canvas');

    canvas.css("width", "100%");
    canvas.css("height", "100%");
}

The HTML code is:

<body>
    <div id="canvas_container">
        <canvas id="my_canvas"></canvas>
    </div>
</body>

And the style is:

#canvas_container
{
    padding: 50px 50px 50px 50px;
    height: 100%;
    width: 100%;
}

#my_canvas
{
    border: 3px solid black;
    width: 100%;
    min-height: 400px;
    height: 100%;
}

body, html 
{
    height: 100%;
}

Am I missing something Safari-specific here in how I am working with the resize event?

I was able to resolve the issue, in fact it had nothing to do with my code, which made it rather hard to debug. I will explain my methodology and the solution in case anyone else encounters this issue.

As I added more and more debugging code to try and figure out what was going wrong I began to suspect that the browser was not running my Javascript (which is in a separate .js file on the server). Eventually I pulled the raw access logs for the server and discovered that while there was a 200 OK log entry for the main page, there was no log entry for the Javascript file.

This behavior was a bit unexpected as standard behavior would be a HTTP GET request with an If-Modified-Since header that would allow the browser to skip downloading the content if the server identifies that the page has not been modified. This would then be recorded as a 304 NOT MODIFIED result in the server's access log.

Comparing the access log for the iPhone session with that of a regular Firefox session on desktop showed that the Firefox browser was requesting all the page assets and getting 304 results and 200 respectively which was recorded in the access log, while the iPhone session had only a request to the main page.

At this point it seemed that Safari had some sort of weird caching mechanism going on which didn't even bother to request the assets. This didn't seem very plausible however, so I continued to investigate until I noticed that the iPhone was requesting the main page on HTTP and not HTTPS (as the desktop version was). I had simply not typed the https:// in the Safari.

Switching Safari to HTTPS resulted in the Javascript being pulled correctly and run. Perhaps this is a consequence of some security policy in Safari.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM