Show file tree
Hide file tree
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[GTK] Try harder to find initial WebKitWebView size
https://bugs.webkit.org/show_bug.cgi?id=226320 Patch by Alexander Mikhaylenko <email@example.com> on 2021-06-01 Reviewed by Michael Catanzaro. Currently we base the viewport size on the drawing area size. The drawing area is created with an initial size based on the viewport size, which will be (0, 0) because the drawing area is still null by that point. Then, later, during the widget allocation, the drawing area receives its proper size. There are 2 issues here. First, this approach guarantees that the initial viewport size will always be (0, 0), and then there's no guarantee the widget will be allocated any time soon - for example, while GtkNotebook in GTK3 does allocate children that aren't currently visible, GtkStack doesn't (and that means that GtkNotebook in GTK4 and HdyTabView don't either). This leads to a situation where a page opened in background will load with 0, 0 size and if a page depends on that, it won't load correctly. The first issue can be fixed by basing the viewport size on the view allocation as well, and then if the widget isn't allocated, we instead try to use the size of a parent as an estimation, so that the initial size is at least not 0 even if not fully accurate. See https://gitlab.gnome.org/GNOME/epiphany/-/issues/1532 * UIProcess/API/gtk/PageClientImpl.cpp: (WebKit::PageClientImpl::viewSize): * UIProcess/API/gtk/WebKitWebViewBase.cpp: (webkitWebViewBaseGetViewSize): * UIProcess/API/gtk/WebKitWebViewBasePrivate.h: Canonical link: https://commits.webkit.org/238338@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@278301 268f45cc-cd09-0410-ab3c-d52691b4dbfc
- Loading branch information
Showing 4 changed files with 88 additions and 3 deletions.