Sometimes the dialog will take gigantic dimensions, to the point where we can only see a completely white window (just a small part of the GtkTreeView drawing area, actually).

I personally notice this effect on low screen resolutions, when the dialog doesn't fit in the screen in the first place, but I was puzzled seeing these exaggerated sizes.

A quick research to determine where these gigantic values are coming from showed the following issues:

1) When a GtkFileChooserWidget shown for the first time it will try to estimate its default size using an heuristic based on the current font-size, DPI, and two constants NUM_LINES(45) and NUM_CHARS(60), but:

e.g, having font-size 16 and DPI 96 would result in:

cairo_units(?) = 21.83 = 16.0 * 96.0 / 72.0 + 0.5;
default_width = 1310 = 21.83 * 60; 
default_height = 982 = 21.84 * 45;

Is already bigger than a commonly used resolution like 1366x768, and these dimensions could be increased more when using a preview widget or extra filters widgets.

2) When a GtkFileChooser dialog is opened a next time it takes the width and height values from gsettings as-is.

e.g. opening the dialog on 1920x1080, closing it, and then reducing the screen resolution (by switching to another output device), will result in the same effect when the dialog is re-opened.

What these two issues have in common is that the current screen resolution is not taken into account.

A quick fix I am trying for this is to contrast the values coming the heuristic and gsettings against the screen/monitor size to default to something smaller.