RESOLVED INVALID 162840
Gtk-WARNING **: Allocating size to WebKitWebViewBase without calling gtk_widget_get_preferred_width/height() 
https://bugs.webkit.org/show_bug.cgi?id=162840
Summary Gtk-WARNING **: Allocating size to WebKitWebViewBase without calling gtk_widg...
Dustin Falgout
Reported 2016-10-01 02:44:26 PDT
This started showing up in logs with GTK 3.20. It's still an issue currently with GTK 3.22. ``` (lightdm-webkit2-greeter:12639): Gtk-WARNING **: Allocating size to WebKitWebViewBase 0x136e3b0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate? ```
Attachments
Add attachment proposed patch, testcase, etc.
Carlos Garcia Campos
Comment 1 2016-10-03 03:08:28 PDT
It's not that this started to happen with GTk+ 3.20, it's that GTK+ added this warning in 3.20. Does it happen all the time with lightdm? It normally happens when a page contains windowed plugins, or when opening the inspector. I don't think we are doing anything wrong, we know the size of the web view, the windowed plugins and the inspector without having to use gtk_widget_get_preferred_width/height()
Dustin Falgout
Comment 2 2016-10-03 07:09:42 PDT
(In reply to comment #1) > It's not that this started to happen with GTk+ 3.20, it's that GTK+ added > this warning in 3.20. Does it happen all the time with lightdm? It normally > happens when a page contains windowed plugins, or when opening the > inspector. I don't think we are doing anything wrong, we know the size of > the web view, the windowed plugins and the inspector without having to use > gtk_widget_get_preferred_width/height() Yeah I've seen the warning with a few of other applications back when 3.20 was released (Nemo is one example that comes to mind). Though whatever was triggering the issue, they must have resolved it because the latest version of Nemo no longer outputs the warning. I looked at it again and it seems that it occurs every time the inspector is opened. It does not occur if you don't open the inspector.
Michael Catanzaro
Comment 3 2016-10-04 05:43:57 PDT
Note that this warning was not intended to be user-visible. In GTK+ 3.22.1 it no longer appears unless you have an --enable-debug build of GTK+.
Dustin Falgout
Comment 4 2016-10-04 10:14:00 PDT
(In reply to comment #3) > Note that this warning was not intended to be user-visible. In GTK+ 3.22.1 > it no longer appears unless you have an --enable-debug build of GTK+. Good to know. Thanks for getting to the bottom of it! :) Shall I close this then?
Michael Catanzaro
Comment 5 2016-10-04 11:32:37 PDT
No, it's still a bug.
Carlos Garcia Campos
Comment 6 2016-10-05 00:00:48 PDT
(In reply to comment #5) > No, it's still a bug. What's the bug exactly? We do know how to allocate the inspector view without querying its size, we know the web view is scrollable and therefore its minimum size is 1. And we know how to allocate the windowed plugins, because their size comes from the web page itself.
Dustin Falgout
Comment 7 2016-10-05 00:28:30 PDT
(In reply to comment #6) > (In reply to comment #5) > > No, it's still a bug. > > What's the bug exactly? We do know how to allocate the inspector view > without querying its size, we know the web view is scrollable and therefore > its minimum size is 1. And we know how to allocate the windowed plugins, > because their size comes from the web page itself. I agree. Seems more like a bug in GTK to me!
Michael Catanzaro
Comment 8 2016-10-05 03:34:47 PDT
(In reply to comment #6) > What's the bug exactly? We do know how to allocate the inspector view > without querying its size, we know the web view is scrollable and therefore > its minimum size is 1. And we know how to allocate the windowed plugins, > because their size comes from the web page itself. I think we should add dummy calls to gtk_widget_get_preferred_width/height() to silence the warning.
Carlos Garcia Campos
Comment 9 2016-10-05 06:49:20 PDT
I don't see why, we are not doing anything wrong, IMO.
Note You need to log in before you can comment on or make changes to this bug.