| Summary: | WKWebView doesn't respect -[UIScrollView contentInset] | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Anders Carlsson <andersca> | ||||
| Component: | New Bugs | Assignee: | Anders Carlsson <andersca> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | ajuma, benjamin, cdumez, cfondacci, commit-queue, fred.wang, oren, rhys, rwlbuis, simon.fraser, thorton | ||||
| Priority: | P2 | ||||||
| Version: | 528+ (Nightly build) | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Attachments: |
|
||||||
|
Description
Anders Carlsson
2014-06-23 18:24:49 PDT
Created attachment 233663 [details]
Patch
Comment on attachment 233663 [details] Patch Clearing flags on attachment: 233663 Committed r170361: <http://trac.webkit.org/changeset/170361> All reviewed patches have been landed. Closing bug. Not supporting content insets was completely intentional. In UIWebView, we have a lot of issues with the interactions between the content insets and the minimal layout size. There are basically two very different use cases that needs different kind of layout. One good example is that Safari cannot work correctly with this implementation. After discussing this a lot, we decided not to support scrolling to the insets and postpone this to a solution that handle layout correctly. Hi I published question about WKWebView not clickable above it's contentInset: http://stackoverflow.com/questions/27755251/wkwebview-isnt-clickable-outside-its-contentinset Is this the same issue? "Not supporting content insets was completely intentional." The current behavior is very surprising though: negative insets work as expected, and positive insets make the floating element move up and down between 0 inset and the specified value. Please see a demo here: https://drive.google.com/file/d/0B63_g2Mv5n4uYkNxWjJWeGR1U1E/view?usp=sharing "we decided not to support scrolling to the insets and postpone this to a solution that handle layout correctly" But it still does something... but not the right thing. It's not that it is not supported, it is that it feels broken. Can you tell us more about "the solution that handle layout correctly" and when this will be available? We are working on a workaround which resizes the webview but it makes footer transparency and overlaying header/footer broken so it is not really satisfying. I don't understand why this bug is marked as "resolved fixed" as it seems neither resolved nor fixed. Tim, what's the current status? Has there been any progress on this? As things stand it's very difficult to build a fairly standard iOS UI where a WKWebview's content 'bleeds' under toolbars and navigation bars. (In reply to Rhys Powell from comment #8) > Has there been any progress on this? As things stand it's very difficult to > build a fairly standard iOS UI where a WKWebview's content 'bleeds' under > toolbars and navigation bars. Could this bug be revisited? The lack of a public API for this means that third-party browsers on iOS cannot implement the transparent toolbars that Safari has. The last time I checked using breakpoints, Safari is using WKWebView SPI to achieve this effect, specifically, some combination of: -[WKWebView _overrideLayoutParametersWithMinimumLayoutSize:maximumUnobscuredSizeOverride:], -[WKWebView _setObscuredInsets], and -[WKWebView _setUnobscuredSafeAreaInsets] |