Created attachment 117387 [details]
gif showing the issue

If it matters, my resolution is 1920x1200, dpi is set to 148

I get the same result here, I think. It shows up where it would have been centered, had it not been expanded. Ie, the same result as if you unexpand it, close it, open it, and expand it :).

I've got the same problem (gtk+ 2.14.4) and it's very annoying because my screen is just 1024x768 and the filechooser is ALWAYS partially offscreen, especially when the location bar is enabled, in which case the filechooser's size is completely messed up. See attached screenshots.

Created attachment 121316 [details]
Screenshot of the filechooser's default size with the location bar

Created attachment 121317 [details]
Screenshot of the filechooser's default size without the location bar

A number of our users have been experiencing similar issues, and even worse. The FileChooser dialog always used to appear with more or less a consistent size. Now, in addition to being mis-positioned half off screen, it is quite frequently to wide, or too narrow, such that you can't make out any of the files supposedly being displayed. Frankly, it's horrible.

This is a regression since upgrading to 2.14 from 2.12.11; certainly, 2.14.4 didn't fix it.

AfC

Created attachment 121328 [details] [review]
dirty fix for the filechooser problems

I went through some distros' bug reporting tools and found these two reports: https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/285285 and http://bugs.gentoo.org/show_bug.cgi?id=239360. There are probably others but wording could be different and popular distros with gtk+ 2.14 are still in beta/rc stage so the userbase is still reduced. Moreover, I don't know if this bug affects all users or if it is masked/created by a specific wm/xorg/drivers/settings combination.

The attached patch, which is what was suggested in those reports, more or less "fixes" it for me, but I'm pretty much sure that it's incorrect and probably has side effects.

Created attachment 121334 [details] [review]
dirty fix for the filechooser problems

The previous patch was probably malformed.

*** Bug 564365 has been marked as a duplicate of this bug. ***

For reference, the commits that broke this:
------------------------------------------------------------------------
r21163 | federico | 2008-08-20 03:11:20 +0200 (mer 20 aoû 2008) | 3
lines

[PATCH 2 [edit]/7] bgo543308 - Remove obsolete sizing code in
GtkFileChooserDialog

------------------------------------------------------------------------
r21162 | federico | 2008-08-20 03:10:59 +0200 (mer 20 aoû 2008) | 3
lines

[PATCH 1 [edit]/7] bgo543308 - Let the file chooser widget be in charge of its
default size; don't force it from the dialog


And a screenshot showing a really too small dialog (I managed to reproduce it with Abiword, for example):
http://bugzilla.gnome.org/attachment.cgi?id=124087&action=view

*** Bug 563549 has been marked as a duplicate of this bug. ***

Bug 559199 and bug 559034 are duplicates, and people provided patches, one very similar to what we have here. It could be good to make them as duplicates, if you have the needed permissions.

Any feedback on the 2-line fixes? They don't appear to raise issues, and fixing this regression should be a priority. Need help?

*** Bug 559034 has been marked as a duplicate of this bug. ***

*** Bug 559199 has been marked as a duplicate of this bug. ***

I'm working on a fix for this.

Milan asked me to pass on comments from bug 559034 which has just been closed as a duplicate of this. From that one:

As the file chooser dialog window opens, first gtk_window_compute_configure_request() is called from gtk_window_show(), and it
actions the GTK_WIN_POS_CENTER_ON_PARENT. But at this point the window size is
only ~ 200x200 pixels.

Then, shortly after that, gtk_file_chooser_dialog_map() is called, it maps the
chooser widget, and then file_chooser_widget_default_size_changed() is called.
The latter calculates the new window size and calls gtk_window_resize() to re-size it to that.

So, the basic problem here is that the centering was done by GtkWindow before
the chooser dialog was mapped, but the chooser does not set its final size
until it is mapped, so the centering is wrong.

I submitted two patches with bug 559034 that are variants of the same fix (the 2nd is probably the better one) which fix it by pre-setting the window size before it is centered by doing it in the constructor.

Fixed in trunk (see commits 22116, 22117, 22118, 22119):

2009-01-14  Federico Mena Quintero  <federico@novell.com>

	Remember the file chooser's geometry across invocations.

	* gtk/gtkfilechoosersettings.h (struct _GtkFileChooserSettings):
	New fields geometry_x, geometry_y, geometry_width, geometry_height.
	(_gtk_file_chooser_settings_get_geometry): New prototype.
	(_gtk_file_chooser_settings_set_geometry): New prototype.

	* gtk/gtkfilechoosersettings.c (GEOMETRY_X_KEY, GEOMETRY_Y_KEY,
	GEOMETRY_WIDTH_KEY, GEOMETRY_HEIGTH_KEY): New key names.
	(ensure_settings_read): Read the geometry keys.
	(_gtk_file_chooser_settings_save): Save the geometry keys.
	(_gtk_file_chooser_settings_init): Initialize the geometry keys to
	"don't have this value".
	(_gtk_file_chooser_settings_get_geometry): New public function.
	(_gtk_file_chooser_settings_set_geometry): New public function.

	* gtk/gtkfilechooserdefault.c (gtk_file_chooser_default_map):
	Don't change the default size in ::map() so we don't flicker...
	(gtk_file_chooser_default_realize): ... so do it in ::realize()
	instead, when the window is not yet visible.  This avoids a
	dialog-that-resizes when you first pop up the file chooser.
	(emit_default_size_changed): Just emit the signal; don't check for
	the widget's state so we can be emitted during the initial
	::realize() when we are not mapped yet.
	(update_preview_widget_visibility): Only emit default_size_changed
	if the widget is not mapped, to avoid resizing the dialog while it
	is visible.

	* gtk/gtkfilechooserdialog.c
	(file_chooser_widget_default_size_changed): Simply resize the
	dialog to the default size without any fancy clamping.  Also,
	leave in place ifdef-ed out code to restore the file chooser's
	position in addition to its size.  The code to restore the
	position doesn't quite work yet, but we'll leave it in as a
	reference.

	* gtk/gtkfilechooserdefault.c (save_dialog_geometry): New function.
	(settings_save): Save the dialog's geometry.
	(gtk_file_chooser_default_get_default_size): Load the geometry
	from the settings.  If it was already saved, return that instead
	of computing an ad-hoc size.

Great! Size is definitely a tricky part of the FileChooser...

Do you think we can expect a bugfix release in the 2.14 series? Else we'll consider backporting patches to Ubuntu. In all cases, I guess the last third patch is sufficient to fix the major issue. Thanks!

(In reply to comment #18)
> Great! Size is definitely a tricky part of the FileChooser...
> 
> Do you think we can expect a bugfix release in the 2.14 series? Else we'll
> consider backporting patches to Ubuntu. In all cases, I guess the last third
> patch is sufficient to fix the major issue. Thanks!

Finally, is there a backport?

Created attachment 129067 [details] [review]
Backport to 2.14.7

It's a straight forward backport, but here's the one that we're using.