After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 691842 - /TreeView/scrolling/specific/bug-111500 fails since "Kill gtk_tree_view_size_request" commit
/TreeView/scrolling/specific/bug-111500 fails since "Kill gtk_tree_view_size_...
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: GtkTreeView
3.7.x
Other Linux
: Normal normal
: ---
Assigned To: gtktreeview-bugs
gtktreeview-bugs
Depends on:
Blocks:
 
 
Reported: 2013-01-16 11:52 UTC by Martin Pitt
Modified: 2013-01-18 00:31 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Revert commit 91949934 (3.12 KB, patch)
2013-01-17 02:39 UTC, John Lindgren
committed Details | Review

Description Martin Pitt 2013-01-16 11:52:45 UTC
When building current GTK+ git master in jhbuild, I get

/TreeView/scrolling/specific/bug-111500: **
ERROR:treeview-scrolling.c:418:assert_position_without_align: assertion failed: (gtk_adjustment_get_value (vadjustment) + gtk_adjustment_get_page_size (vadjustment) >= row_start + row_height)

This happens in a clean minimal Ubuntu server installation with most sysdeps built in jhbuild (and of course glib, themes, etc.) when running under Xvfb, as well as in jhbuild when running under Ubuntu's X.org server and Unity session with it's own GNOME themes, so this looks unrelated to the precise theme and bug 585493. Running the test under jhbuild and without xvfb-run shows that the builtin default theme is being used, as expected.

The test succeeds when building GTK 3.6.4 in our minimal build environment (i. e. when running "make check" during GTK package build). So I check out 3.6.4 in git and do a clean build in jhbuild, under otherwise the same circumstances, and the test succeed.

This seems to indicate an actual regression somewhere between 3.6.4 and 3.7.4?

I'm going to bisect this now.
Comment 1 Martin Pitt 2013-01-16 12:44:08 UTC
This regression appears with this commit:

http://git.gnome.org/browse/gtk+/commit/?id=d0e0e489423e424075e7db400a079

Interestingly, this also explains the change to PyGObject's test cases this morning in http://git.gnome.org/browse/pygobject/commit/?id=4706cd68: merely calling get_preferred_size() on the tree view does not realize it enough any more to actually initialize the cells; I guess this is not really a bug, but it might hint to why that test case now fails.
Comment 2 John Lindgren 2013-01-17 02:39:37 UTC
Created attachment 233646 [details] [review]
Revert commit 91949934
Comment 3 John Lindgren 2013-01-17 02:39:59 UTC
The commit at fault is actually this one (the later commit must have somehow unmasked the regression):

http://git.gnome.org/browse/gtk+/commit/?id=919499345395fc89e413529598f6f307456cb904

This commit can be reverted with some slight differences, allowing the test to succeed again.  Patch is attached.