Changing WKWebView ScrollView’s contentInset results in wiggle while selecting a text inside content editable <div>

It is best to avoid attempting to mix native UI elements with a web view. Don't mess around with the scrollviews at all. If you need to do something in the web view use CSS and Javascript. Since you are in a restricted web view, you don't have to worry about browser compatibility.

Thanks John for you suggestion. I'm actually trying to replicate something simiar to iOS native mail's email compose screen. Top part is native UI and the botton part is to add the body content with rich text capablities.
Sample project - https://github.com/mohanio/WKWebViewScrollInset

Repro video - https://drive.google.com/file/d/1yUP4axcnrTWg48eQvJvTSJbh1eFso7NP/view?usp=sharing

I don't know what else to tell you. Your video doesn't show anything. It is mostly black. Your sample project shows that you did accurately describe what you are attempting.

What I am saying is that you should consider a web view to be an opaque object. Don't try to do anything with its scroll views directly. Even if, somehow, you get to to where where every one else has failed, you stand an excellent chance of having it all break again with some minor OS update. How are you going to fix it then?

There is no problem having a web view that occupies only a portion of another view. That's fine. Just stay out of the internals. Maybe use a stack view with the header on top and the content below. You might need to calculate how big your web view really is and resize it to match so that only the top-level scroll view is useful. You don't want double-scrolling, unless you do.

Sorry for wrong video link, update with correct link now.

Got your point, but why is scrollView property of WKWebView exposed to public if WebKit doesn't want us to alter any of its properties ?

Also, webview's scrollview content inset is adjusted in other scenraios like safe area insets(eg. content inset of scrollview is adjusted automatically if WebView underlaps UINavigationBar).

I tried by setting ViewController's additionalSafeAreaInsets property to UIEdgeInsetsMake(200.0, self.additionalSafeAreaInsets.left, self.additionalSafeAreaInsets.bottom, self.additionalSafeAreaInsets.right); and the issue is not observed in this scenario but the only problem is scrollview ignores any interaction that happen in top 200 pixels so, scroll won't happen while dragging inside 0 to 200.

I'm just thinking think from a point of view where its is a bug in webkit.

why is scrollView property of WKWebView exposed to public if WebKit doesn't want us to alter any of its properties ?

I am the one that doesn't want you messing with the scroll views, not WebKit.

I'm just thinking think from a point of view where its is a bug in webkit.

That's funny. You mean "a bug", as in singular? It's riddled with bugs. And I'm only talking about things that it is supposed to be able to do. On the Mac, it still doesn't have major features like printing.

You just have to be very careful with web views. You should not attempt to use them as regular views. Use them as opaque views. They have their own scroll views. If you want to control how scrolling works, you should do that via Javascript or CSS. You might be able to find some magic combination that works today, but it might not work tomorrow.

I'm a pretty heavy user of web views. I commonly run into the same bugs and problems that other people encounter. I can search the usual places on the web and find literally dozens of different suggestions that are guaranteed to work. Not a single one will work.

On the bright side, once I'm inside the view itself, in HTML/JS/CSS, I find it to be very reliable. I don't have to worry about cross-browser issues.

You have a couple of options. You can put everything inside the web view, which is easy enough. Or, you can stretch the web view to accomodate all of your input and put both your webview and header inside a scroll view.