Skip to content
Permalink
Browse files
[GTK] Try harder to find initial WebKitWebView size
https://bugs.webkit.org/show_bug.cgi?id=226320

Patch by Alexander Mikhaylenko <alexm@gnome.org> 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
Exalm authored and webkit-commit-queue committed Jun 1, 2021
1 parent cacd1f7 commit 72fbd991a0d32147ed7fd63a7ac083b93e7d8545
Show file tree
Hide file tree
Showing 4 changed files with 88 additions and 3 deletions.
@@ -1,3 +1,40 @@
2021-06-01 Alexander Mikhaylenko <alexm@gnome.org>

[GTK] Try harder to find initial WebKitWebView size
https://bugs.webkit.org/show_bug.cgi?id=226320

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:

2021-05-30 Dean Jackson <dino@apple.com>

[WebXR] Send recommendedResolution using DeviceProxy
@@ -103,8 +103,7 @@ WebCore::FloatPoint PageClientImpl::viewScrollPosition()

WebCore::IntSize PageClientImpl::viewSize()
{
auto* drawingArea = static_cast<DrawingAreaProxyCoordinatedGraphics*>(webkitWebViewBaseGetPage(WEBKIT_WEB_VIEW_BASE(m_viewWidget))->drawingArea());
return drawingArea ? drawingArea->size() : IntSize();
return webkitWebViewBaseGetViewSize(WEBKIT_WEB_VIEW_BASE(m_viewWidget));
}

bool PageClientImpl::isViewWindowActive()
@@ -263,6 +263,7 @@ struct _WebKitWebViewBasePrivate {
#endif
std::unique_ptr<PageClientImpl> pageClient;
RefPtr<WebPageProxy> pageProxy;
IntSize viewSize { };
bool shouldForwardNextKeyEvent { false };
bool shouldForwardNextWheelEvent { false };
#if !USE(GTK4)
@@ -891,8 +892,10 @@ static void webkitWebViewBaseSizeAllocate(GtkWidget* widget, GtkAllocation* allo
}
#endif

priv->viewSize = viewRect.size();

if (auto* drawingArea = static_cast<DrawingAreaProxyCoordinatedGraphics*>(priv->pageProxy->drawingArea()))
drawingArea->setSize(viewRect.size());
drawingArea->setSize(priv->viewSize);
}

#if USE(GTK4)
@@ -2362,6 +2365,51 @@ void webkitWebViewBaseSetFocus(WebKitWebViewBase* webViewBase, bool focused)
webkitWebViewBaseScheduleUpdateActivityState(webViewBase, flagsToUpdate);
}

IntSize webkitWebViewBaseGetViewSize(WebKitWebViewBase* webViewBase)
{
WebKitWebViewBasePrivate* priv = webViewBase->priv;
int width = priv->viewSize.width();
int height = priv->viewSize.height();

// First try the widget's own size. If it's already allocated,
// everything is fine and we'll just use that.
if (width > 0 || height > 0)
return IntSize(width, height);

GtkWidget* parent = gtk_widget_get_parent(GTK_WIDGET(webViewBase));

// If it's not allocated, then its size will be 0. This can be a problem
// if the web view is loaded in background and the container doesn't
// allocate non-visible children: e.g. GtkNotebook in GTK3 does allocate
// them, but GtkStack, and so GtkNotebook in GTK4 and HdyTabView don't.
// See https://gitlab.gnome.org/GNOME/epiphany/-/issues/1532
// In that case we go up through the hierarchy and try to find a parent
// with non-0 size.
while (parent) {
#if USE(GTK4)
width = gtk_widget_get_width(parent);
height = gtk_widget_get_height(parent);

if (width > 0 || height > 0)
#else
width = gtk_widget_get_allocated_width(parent);
height = gtk_widget_get_allocated_height(parent);

// The default widget size in GTK3 is 1x1, not 0x0.
if (width > 1 || height > 1)
#endif
return IntSize(width, height);

parent = gtk_widget_get_parent(parent);
}

// If there was no such a parent, it's likely the widget widget isn't
// in a window, or the whole window isn't mapped. No point in trying
// in this case.

return IntSize();
}

bool webkitWebViewBaseIsInWindowActive(WebKitWebViewBase* webViewBase)
{
return webViewBase->priv->activityState.contains(ActivityState::WindowIsActive);
@@ -64,6 +64,7 @@ void webkitWebViewBaseUpdateTextInputState(WebKitWebViewBase*);
void webkitWebViewBaseSetContentsSize(WebKitWebViewBase*, const WebCore::IntSize&);

void webkitWebViewBaseSetFocus(WebKitWebViewBase*, bool focused);
WebCore::IntSize webkitWebViewBaseGetViewSize(WebKitWebViewBase*);
bool webkitWebViewBaseIsInWindowActive(WebKitWebViewBase*);
bool webkitWebViewBaseIsFocused(WebKitWebViewBase*);
bool webkitWebViewBaseIsVisible(WebKitWebViewBase*);

0 comments on commit 72fbd99

Please sign in to comment.