First of all everything works perfectly on UIWebView on all possible iOS versions so this is a specific WKWebView issue.

After I've pleted the implementation of WKWebView I bumped into a massive graphical bug/issue. In portrait my application works fine but when I rotate it to landscape something strange happens, my header and footer are not rendering correctly.

If I look into my webcode I can see that the CSS width is getting updated in the DOM with the correct data but I can only see the width of portrait orientation ( 320px ) of the header/footer even though it reads style=“width: 568px;” in the DOM.

I'm using positioning:fixed but if I'm changing to positioning:relative it renders as expected on screenrotation (unfortunately relative positioning isn't an option in this case). If I click on the header/footer or scroll somewhere on the screen the header and footer somehow updates and renders correctly and are shown as expected (only requires 1px of scrolling).

I will try to illustrate how it looks like.

Red = Visible
Blue = Invisible (even though it's there and events launches on click/scrolling).

Anyone experienced this issue before and got a solution?

First of all everything works perfectly on UIWebView on all possible iOS versions so this is a specific WKWebView issue.

After I've pleted the implementation of WKWebView I bumped into a massive graphical bug/issue. In portrait my application works fine but when I rotate it to landscape something strange happens, my header and footer are not rendering correctly.

If I look into my webcode I can see that the CSS width is getting updated in the DOM with the correct data but I can only see the width of portrait orientation ( 320px ) of the header/footer even though it reads style=“width: 568px;” in the DOM.

I'm using positioning:fixed but if I'm changing to positioning:relative it renders as expected on screenrotation (unfortunately relative positioning isn't an option in this case). If I click on the header/footer or scroll somewhere on the screen the header and footer somehow updates and renders correctly and are shown as expected (only requires 1px of scrolling).

I will try to illustrate how it looks like.

Red = Visible
Blue = Invisible (even though it's there and events launches on click/scrolling).

Anyone experienced this issue before and got a solution?

• javascript
• css
• objective-c
• render
• wkwebview

• can u post actual html css code for the top nav bar ? – krisrak Commented Dec 5, 2014 at 16:54
• Did you ever figure this out? I'm running something similar which I think stems from the same rendering problem. – raphael Commented Sep 23, 2015 at 22:08
• Check Justin Michael answer in the bottom of the thread. – HampusZetterberg Commented Sep 24, 2015 at 10:38

6 Answers 6

Not the best fix but here's a work around. It looks like WKWebView doesn't invalidate it's content on rotation changes but does invalidate it on scroll (see here: https://github./WebKit/webkit/blob/master/Source/WebKit2/UIProcess/API/Cocoa/WKWebView.mm#L1430). Since scrolling will invalidate it and force the CSS to re-render you could do something like this:

extension WKWebView {
    func invalidateVisibleRect() {
        let contentOffset = scrollView.contentOffset
        scrollView.setContentOffset(CGPoint(x: contentOffset.x, y: contentOffset.y + 1), animated: true)
    }
}

You could use that for now until the radar gets fixed.

UPDATE:

Supposedly this behavior will be fixed in iOS 9.

I'm having the same issue in an app where I am not in control of the HTML content so I can't alter the javascript to kludge this.

Bugs won't get fixed unless Apple's engineers know that they exist. I couldn't find a reference to this problem in the bug reporting system so...

Please report this to Apple at bugreport.apple. to expedite a fix

You can reference bug report 20568425 : CSS elements within a WKWebView do not layout correctly when the device is rotated

I thought I was the only one! :) I am using the Xamarin "version" of the WKWebView, and have the EXACT same issue. From what I suspect its the WKWebView itself not updating the page layout correctly and I haven't been able to find any code to force it to.

So, while its not a proper solution, what I've landed up doing for now is to inject some javascript into the page on screen rotation to set the width of the header\footer. The width adjustment is slightly noticeable but at least it resolves itself without the need to scroll the page.

Hope this helps, at least until the issue in WKWebView is properly resolved.

This was happening to me as well, and after a lot of trial and error I was able to fix it, in my case, with the following JavaScript/jQuery code in the web content:

$(window).on('resize', function () {
    setTimeout(function () {
        window.scrollTo(0, 0);
        window.scrollTo(0, 1);
    }, 700);
});

A few notes about this solution:

• This works for me because the web content I'm loading consists entirely of fixed elements that have overflow: auto set for scrolling content within them. Thus, I never scroll the entire page, so I'm free to reset the scroll position to 0, 0. If your entire page scrolls you can probably adapt this technique by adding or subtracting 1 from the scroll position, but be careful; the page has to actually scroll for it to work. If the scrollY of your page maxes out at, say, 3000 and you try setting it to 3001 that won't work, you'd need to do 2999.
• The timeout value of 700 is probably excessive for your purposes; try reducing it.

I tried just about everything else I could think of; the only solution I could find that work reliably was to force a scrolling change after the rotation event.

Looking forward to this being fixed!

As other people said, it should be a bug, below is my javascript fix, hope it work for you or somebody:

//fix IOS WKWebview rotate bug
var viewport_width = $(window).width();
var viewport_height = $(window).height();
setInterval(function(){
    if($(window).width()!=viewport_width || $(window).height()!=viewport_height){
        viewport_width = $(window).width();
        viewport_height = $(window).height();
        window.location = '#wkwrf';
        window.history.back();
    }
}, 200);

Fixed the similar issue in https://github./WayneLin1215/Swift-WKYoutubePlayer. By modifying window.onresize method in YTPlayerView.html template:

window.onresize = function() { setTimeout(function() { player.setSize(window.innerWidth, window.innerHeight) }, 100); }