Bug 254926 – REGRESSION (iOS 16.4): Cordova APP Webview CSS position:fixed not work correctly

• Component: CSS
• Status: NEW

[Kevin Siml]

Created attachment 465748 [details]
iOS 16.4 Simulator Video

Hello, I develop APPs with Cordova and xCode based on HTML, JavaScript and JS and the iOS WebView. since iOS 16.4 CSS > position:fixed does not work as expected. after scrolling, the fixed element jumps down exactly as far as you scroll. This problem still occurs with iOS 16.5 beta. It occurs on real devices as well as in the simulator! I am sending a video of the problem. I ask for a fix. Thank you Kevin Siml

[Radar WebKit Bug Importer]

<rdar://problem/107615708>

[Matt]

Also experiencing this issue with our Cordova app on iOS 16.4 as well as the 16.5 beta.  Has anyone found a workaround for this?

[Karl Dubost]

Not yet but making progress in Bug 254936
on what is happening. 

Matt, if there is a web app somewhere with code example when this is reproducing, that would be very helpful to find a regression range.

[Matt]

Here's the markup we are using to test.  Works in iOS 16.2 and lower.  Can't find a device or emulator to test 16.3.  Header will start to jump when using 16.4 and 16.5 beta.  Our iOS app uses UIWebView but we are working on doing some testing on WkWebview today as well. https://github.com/mnewc14/demos/blob/main/fixedHeaderTest.html

[sanchez]

has any solutions?

[Simon Fraser (smfr)]

The best solution is to migrate from UIWebView to WKWebView.

[Kris Sebesta]

A WORKAROUND: We ran into this issue as well. Since upgrading to WKWebView broke our ajax calls (XHR would not populate, a known limitation!) and none of the other ajax/XHR fixes proposed by other devs actually worked, so  we went with a simple fix/hack. We added a function on the scroll event (like so... "document.addEventListener('scroll', function() {}") and we set the element.style.top = '0px;' in the function.  Then, THIS IS IMPORTANT, we created a timer (like so... "setTimeout(function() { set element.style.top = previousTopValue }, 0);") and in that function we set it back to the value it was before we set it to 0px. This triggered the browser to force the page to correctly redraw every time the user scrolled (it needs the timer in order to redraw it, otherwise it won't work). You can still see the fixed element detatch from its fixed position (and scroll down) but the fix/hack will immediately redraw the page correctly. Hope this helps!

[Kris Sebesta]

A WORKAROUND UPDATE: We needed to switch from the 'scroll' event to the 'touchstart' and 'touchend' events because sometimes the scroll event would not fire.