Attached is what I see. Left is 4.4 built a couple days ago, right is 4.3.1.2 release. Looks like 4.4 is actually taller but same width? You seeing something different Cor?

Created attachment 105666 [details]
Dialogs 4.1.3.2 release vs. 4.4

Created attachment 105677 [details]
Screenshots in Daily and 431

Hi Joel,
See my screenshots attached

Hi!

Checked in daily from 20140902.

With a clean user profile, or a clean usermodifications.xcu, it works fine (now).
(looks as if I caused an error with copying profiles around. Not sure. But apologies nevertheless.)

Kind regards,
Cor

Ah, found the problem :)

I often open a file by copying full name (path + name) from the file manager to the field "File name" in the dialog "Open".
And then hit Enter.
Now if that full name is long.. the next time I do Ctrl+O the dialog ís very wide.

Moving back to UNCONFIRMED so someone can confirm with new instructions.

Joel, I've been doing QA from back in 2004 or so.
The summary of this bug already explains how to reproduce.
(I would love to see more attention for that key information, rather then some ... :( )

@Cor - bugs should still be confirmed by a third party independent triager (I never confirm my own bugs) - anyways, it was set to REOPENED which was wrong status regardless, NEW is more appropriate.

(In reply to Joel Madero from comment #8)
> @Cor - bugs should still be confirmed by a third party independent triager
> (I never confirm my own bugs) - anyways, it was set to REOPENED which was
> wrong status regardless, NEW is more appropriate.

If I take freedom to set my own bugs to new, I'm confident.
Maybe some additional testing reveals that it's e.g. related to CPU (32 bits) but then that will be clear.

Hi,

Why is this minor? It looks ugly, and there is no means to bring back a normal size, unless I dump my config.. (or hack it ;) )

Cor, why does that matter? I’m planning to do tweaks to reduce its size, please give me a few days.

For reference it looks like it was this UI conversion that changed the behaviour

commit f90eb33a268bdcd1c52aea5670a58267b0907096
Author: Szymon Kłos <eszkadev@gmail.com>
Date:   Sat Jun 28 16:10:39 2014 +0200

    DLG_FPICKER_EXPLORERFILE conversion to .ui
    
    Change-Id: I5d8f5d0182fb6af5111b60caa29912d313c2efa0

Created attachment 113689 [details]
photo of the dialog

dialog widens to flow over two screens..

== For the context ==
I prefer put my comment in this Bug (because of a bigger history) than in mine (https://bugs.documentfoundation.org/show_bug.cgi?id=92867) which actually seems to be a duplicate. (I would agree if you do it but don't do it myself, because I do not know the architecture of the software).

== Remark ==
What I understand from outside is, that it seems there is something like a window template/container whose width is given by the templatedWindow/content.
_
Fine: let's avoid developing twice the same thing


Some of the windows are defining there opening width dynamically (in this bug, using the previous inputed string / in my bug, using the max string size of all elements of the selected column)
_
Fine: let's give some freedom to the customisation

_
What is here missing are some borders into the template/container


_____
As a regular SW tester I see the possible problems which could come from this fix and want to give them here, in the form of specifications (based on what I would expect) - please consider, I am ONE (not all the other users) and my perception is perhaps false or GNOME oriented (I don't know -and care- about the other UIs):

I will use:
- size to avoid writing twice for width and height
- template for the container or the template (I don't know how it works)
- final window for the customized window based on the template or into the container


1/ The wished size must be defined by the final window

2/ The application adequate size must be the limitation to the application width of the wished size(computed at the template level)

3/ The probable size must be the limitation to a minimum readable size (given by the final window)

4/ The size is a limitation of the probable size to the desktop (or current screen?) size at the template level


==> the check 3 will make me happy because I often split vertically a screen with 2 applications and I don't want to have really unreadable windows because of that 
==> the check 4 is just because I am a fan of "belt and suspenders" solutions and as library provider never trust my users :D

For the record, if my bug is closed, please consider: earlier version affected for this bug should be changed to 4.2.8.2 (maybe it helps for the investigation)

(In reply to romain from comment #14)
> mine (https://bugs.documentfoundation.org/show_bug.cgi?id=92867) which
> actually seems to be a duplicate.
That's not a duplicate for sure, just a similar bug.

I agree but I am sure that if all the discussion is grouped into one bug, it would have more weight to choose to resolve it.

(then I will come back with my Bug and say: can you please fix it here also? :D)

Set this to fixed with commit https://gerrit.libreoffice.org/#/c/18844/1 from Caolan. For which thanks!

Backported to -5-0: http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-5-0&id=ce75966ae16381353fe75f9df2f56d03b8861cd5

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