Uzbl

This is not unique to xfce, I can now confirm it on KDE and DWM as well. Downgrading webkit solves the problem.

This has started happening to me recently. It makes uzbl useless for now

Oh, I have tested under DWM and Metacity

I've confirmed that downgrading to webkit 1.1.5 instead of 1.1.12 fixes this

The guys at webkit-gtk say this is an introduced _feature_ in 1.1.12. The webkit-gtk "widget will request the size it needs to render all of the content". Consider this a bug in uzbl.

Reference commit in webkit: https://bugs.webkit.org/show_bug.cgi?id=17154

Here is my patch to stop the window from growing; http://unixangst.com/uzbl_webkit_scrolled_win_fix.patch

It also takes care of scroll_[vert|horz|begin|end] but someone who actually KNOWS gtk or c coding for that matter should probably fix it, compiles fine without warnings and seems to work the way it was intended (but I have never used uzbl with an older webkit, so I had to guess)

Israel Levin asked me to merge this: http://github.com/israellevin/uzbl/commit/965ac03d49ab8563813514c56c8bbcb115d95379

is this good stuff?

I wrote a quick fix based on a post someone made to this tasklist. Not even sure why it works, but it seems to. Just got merged into experimental, so check it out.

I'm sorry, that was a bit misleading of me. In case it's not yet clear, my fix was not MERGED into experimental, which sort of suggests Dieter's experimental, it was COMITTED to experimental, that is to say my experimental now linked above. In any event, it currently works for me and I finally don't have to pin libwebkit on my sid machines.

I can confirm both the problem and the fix. On the other hand, it could also be solved in one line (c. 2795) at the end of retrieve_geometry():
gtk_widget_set_size_request(GTK_WIDGET(uzbl.gui.main_window),1,1);
The committed fix is probably the more robust solution.

I'm having the EXACT same problem. I fixed it another way though. In the main function I changed:

gtk_scrolled_window_set_policy(GTK_SCROLLED_WINDOW(scrolled_window),
GTK_POLICY_NEVER, GTK_POLICY_NEVER);


to...

gtk_scrolled_window_set_policy(GTK_SCROLLED_WINDOW(scrolled_window),
GTK_POLICY_AUTOMATIC, GTK_POLICY_AUTOMATIC);

Oh wait, Thomas already had that in his patch. Sorry, didn't see it.

Listen guys, I use a tiling WM so I can't take the lead here.
There are 4 different patches here but I can test none.

diff per patch:
Bill: 1 line
Sean: 1 line (I'm not sure just changing the policy is a good idea. I think we even changed it in the past, the 'never' is probably there for a reason)
Israel: 4 lines
Thomas: many lines

Discuss with each other what is the best solution (the simpler the better) and when done, let me know which i should merge.

I am experiencing this problem in a tiling WM (DWM). It does not show immediately upon page load, but once the window gets moved about in the layout and changes size it gets out of control. Can't scroll it, can't resize it, and it sort of gets floated off the layout. I should check if this persists when I ignore size hints.

If we are already collecting all the fixes, than I started out based on this suggestion:
http://www.uzbl.org/bugs/index.php?do=details&task_id=99

It's only two lines, but it produces compilation warnings, so I checked some GTK sample code and saw the more conventional way of doing it. Warning free.

I have to admit that Sean's patch is the only one that makes sense to me (which means I can sort of understand why it works without knowing much about GTK). Does anyone care to explain why setting the window's minimal size (which is what Bill and me are doing) solves our problem?

Putting a few things together from this topic, it seems that webkit is requesting a gtk_vbox large enough for the entire page. The ways to deal with this are either to tell GTK to use scrollbars, as Sean does (http://www.gtk.org/api/2.6/gtk/GtkScrolledWindow.html which sounds like they're meant to be displayed), or to have the size request not honored, as Israel and I do.

With the overly-large gtk_vbox contained in a scrolled window, a smaller window size just means that not everything will be displayed at once. That's why setting the minimum size to the smallest allowable works---it overrides the huge size request of webkit, and because everything is scrolled, it doesn't have side-effects. Furthermore, with the minimum size changed instead of the scroll policy, the scroll bars should never appear. Changing the policy seems to open the door for scroll bars appearing.

As for which of the set-minimum-size patches to use, I suggest placing my line in his location. Using the geometry hints would make sense if they were dynamic or if there were a maximum size we were aiming for, but it looks like Israel's patch and mine come to the same thing in this case. Placing the size request in his location (at the end of create_window, c. 2394) seems to have the benefit of both simplicity and being less frequently called than my original placement (chosen to really hammer the point home that I wanted to resize it).

Here's maybe a decent explanation from http://library.gnome.org/devel/gdk/unstable/gdk-Windows.html#GdkGeometry:
"gdk_window_set_geometry_hints() expects the hints to be fully valid already and simply passes them to the window manager; in contrast, gtk_window_set_geometry_hints() performs some interpretation. For example, GtkWindow will apply the hints to the geometry widget instead of the toplevel window, if you set a geometry widget. Also, the min_width/min_height/max_width/max_height fields may be set to -1, and GtkWindow will substitute the size request of the window or geometry widget. If the minimum size hint is not provided, GtkWindow will use its requisition as the minimum size. If the minimum size is provided and a geometry widget is set, GtkWindow will take the minimum size as the minimum size of the geometry widget rather than the entire window. The base size is treated similarly. "

Shouldn't we set the max size too? I wrote a patch (https://dl.getdropbox.com/u/1720529/inclmaxsize-ubzl.patch) for that that includes the fix from http://www.uzbl.org/bugs/index.php?do=details&task_id=99

Oh, I certainly do not want scroll bars.

Trying your suggestion, I discovered that the set-size request does not solve the problem when placed at the end of create_window. I guess that it has to be in retrieve_geometry so it will be called every time a page loads and tries to change the window size, and that setting the geometry hints does that automatically.

I am still not completely clear on why setting a minimum size overrides webkit's size request. We are telling the window to be AT LEAST 1x1, right? That means anything above that value, including the huge size webkit is requesting, is legit. Does the mere fact that there is a size request makes the window ignore webkit's request?

Based on this assumption I managed to slim my version down quite a bit. It's now a single line just before the end of create_window as follows:
gtk_window_set_geometry_hints(GTK_WINDOW (window), NULL, NULL, GDK_HINT_MIN_SIZE);

Note that I am not setting any minimal size, just passing null. And it works.

Committing this to my fork, for your gitting pleasure.

The scrollbars aren't actually displayed though. The window adjusts to the scrollbars as if they are displayed.

I think you've hit the nail on the head Israel. I'll confirm that the fix is working for me, and that it strikes me as the correct use of GTK. My issue with the scroll policy is that a) it seems like it should be unrelated, and b) that we should allow the window to be resized to 1x1 on principle anyway.

Just a remark for those who use a tiling window manager, changing your setting for handling size hints may solve this problem.

I'm using DWM, and setting resizehints to False in config.h made it go away.

I have read some GTK documentation - which made me feel all dirty inside, but such are the sacrifices one faces in the search for knowledge - and I finally think I understand why the fix works. It doesn't matter what minimal size we set (passing null we just don't), all that matters is the last arguments, which asks GTK to pay attention to our (non-existing) minimal-size-hint and forget about webkit's.

Ignoring webkit's min-size hint sounds like a good thing in general. Should I ask Dieter to merge?

I'd say that sounds like a reasonable assessment of what is going on, and will recommend the merge.

Nice find guys.
I was told that the webkitgtk+ behavior is different in 1.1.14 and this issue should be totally gone if compiled against webkitgtk+ 1.1.14.

can you guys confirm this?

maybe:
1. Open uzbl.c
2. Find in function - retrieve_geometry() strings:
gtk_window_get_size(GTK_WINDOW(uzbl.gui.main_window), &w, &h);
gtk_window_get_position(GTK_WINDOW(uzbl.gui.main_window), &x, &y);
3. Replace:
gtk_window_set_size(GTK_WINDOW(uzbl.gui.main_window), &w, &h);
gtk_window_set_position(GTK_WINDOW(uzbl.gui.main_window), &x, &y);

This don't work:
> maybe:
...
> gtk_window_set_position(GTK_WINDOW(uzbl.gui.main_window), &x, &y);

But Window random resize, i don't know why.

I was experiencing this issue in Gnome 2.26.1 in Ubuntu 9.04 w/ the latest uzbl code from Git. I compiled webkitgtk 1.1.14 and rebuilt uzbl against it; this seems to have solved the issue. I believe the lib version I had before (from the Ubuntu Webkit Team repo) was ~1.1.12, though I'm not 100% sure as they have a few different versions in their repo.

This issue was consistently happening when browsing around the uzbl site before. However, all of the pages no longer stretch the window / disable resizing with the new build. :)

I can confirm that with webkitgtk 1.1.14 and 1.1.15 the problem seems to be gone in normal uzbl. However I still have it with uzbl_tabbed.py.
Uzbl version: Commit: 01ce2a70bddb831c77a5f6eabd35a85b0549095f

Also, it took me some time to figure out how to build webkitgtk, as the build-webkit script doesn't tell you about missing dependencies. (And the build 'guide' on their website doesn't even mention linux)
You can just use ./autogen.sh and have a familiar build-process that tells you what's going wrong.

- uzbl now depends on libwebkit 1.1.15 or higher
- geometry behavior is now improved (in both master and experimental). see http://github.com/Dieterbe/uzbl/commit/1461ac760f79b8f153c8317c4534cb047a48331a

if this problem continues to exist with a recent uzbl + libwebkit 1.1.15, feel free to reopen this ticket