| Summary: | WKWebView contents is offset at startup (top inset) | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | gmorin | ||||
| Component: | WebKit API | Assignee: | Nobody <webkit-unassigned> | ||||
| Status: | NEW --- | ||||||
| Severity: | Normal | CC: | akeerthi, hi, simon.fraser, smoley, thorton, webkit-bug-importer, wenson_hsieh, zalan | ||||
| Priority: | P2 | Keywords: | InRadar | ||||
| Version: | Safari 14 | ||||||
| Hardware: | Mac (Intel) | ||||||
| OS: | macOS 11 | ||||||
| Attachments: |
|
||||||
Thanks for filing, ccing relevant folks. Would be super interested to know if https://trac.webkit.org/changeset/279708/webkit fixes this. |
Created attachment 433886 [details] Two sample projects On app startup, contents loaded in a WKWebView is offset vertically. We’ve found that this behavior only occurs when the following conditions are met: - The window containing the webview is configured to use a Full Size Content View - The window's title bar is not transparent We provide two sample applications which allow reproduction of the bug. - The first one shows the most basic way to reproduce the problem. We could easily use some workarounds to avoid the problem, such as refrain from using safe area guides and adjust the webview’s constraints to prevent the webview from appearing under the toolbar. - The second one shows a more complex example, with a full height sidebar while the webview appears on the content’s side of the SplitView. We've found that the problem seems to come from WebViewImpl, where a top inset is set using the following conditionL: `if ((window.styleMask & NSWindowStyleMaskFullSizeContentView) && !window.titlebarAppearsTransparent && ![m_view enclosingScrollView]) { ... }` Somewhat curious is the fact that slightly moving or resizing the window redraws the webview correctly and removes the inset...