CSS rendering problems with WKWebView when rotating the screen

Question

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

After I completed the implementation of WKWebView, I ran into a massive graphical error / problem. In the portrait, my application works fine, but when I rotate it into the landscape, something strange happens, my headers and footers do not display correctly.

If I look at my web code, I can see that the CSS width is updated in the DOM with the correct data, but I can only see the portrait orientation width (320 pixels) of the header / footer, even if it reads style="width: 568px;" in the DOM.

I use positioning:fixed , but if I move on to positioning: relative, it displays as expected when scrolling (unfortunately, relative positioning is not an option in this case). If I click on the header / footer or scroll somewhere on the screen, the header and footer somehow update and display correctly and display as expected (only 1px scroll is required).

I will try to illustrate how it looks.

Red = Visible
Blue = Invisible (even if it is there and events are triggered by clicking / scrolling).

Has anyone experienced this problem before and got a solution?

Answer 1

I have the same problem in an application where I do not control the HTML content, so I cannot change javascript for this.

Errors will not be fixed if Apple developers do not know that they exist. I could not find a link to this problem in the error reporting system, so ...

Report this to Apple at bugreport.apple.com to expedite the fix.

You can refer to error report 20568425: CSS elements in WKWebView do not display location correctly when device is rotated

Answer 2

Not the best solution, but work here. It seems that WKWebView does not cancel its contents when the rotation changes, but makes it invalid in the scroll (see here: https://github.com/WebKit/webkit/blob/master/Source/WebKit2/UIProcess/API/Cocoa/WKWebView .mm # L1430 ). Since scrolling will invalidate and force CSS to re-render, you can 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 can use this until the radar is fixed.

UPDATE:

Presumably, this behavior will be fixed in iOS 9.

Answer 3

I thought I was the only one! :) I am using the Xamarin "version" of WKWebView and have the EXACT same problem. From what I suspect, WKWebView itself does not refresh the page layout correctly, and I could not find any code to force it.

So, although this is not the right solution, what I came up with now is to insert some javascript into the page on the screen to set the width of the header \ footer. The width adjustment is a little noticeable, but at least it is allowed without having to scroll the page.

We hope this helps, at least until the issue in WKWebView is resolved correctly.

Answer 4

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

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

A few comments about this solution:

• This works for me, because the content of the web content that I download consists entirely of fixed elements that have overflow: auto set to scroll the content inside them. That way, I never scroll the whole page, so I'm free to reset the scroll position to 0, 0 . If all the scrolls of the entire page, you can probably adapt this method by adding or subtracting 1 from the scroll position, but be careful; the page should actually scroll for it to work. If the scrollY value of your page exceeds 3000, and you are trying to set it to 3001, which will not work, you will need to do 2999.
• A timeout value of 700 is probably excessive for your purposes; try to reduce it.

I tried everything I could think; the only solution I could find that working reliably is to force a scroll change after the rotation event.

We expect this to be fixed!

Answer 5

As other people said, this should be a mistake, below is my javascript fix, hope this works for you or someone else:

 //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);