Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a6pre) Gecko/20070619 Minefield/3.0a6pre Mozilla/5.0 (X11; U; Linux i686; en-US; rv:126.96.36.199pre) Gecko/20070619 BonEcho/188.8.131.52pre Thunderbird version 3.0a1pre (20070618) Thunderbird version 184.108.40.206pre (20070619) Steps to Reproduce: 1. Start firefox -P or thunderbird -P 2. Create some profiles so that there are 14 or more profiles in the list, and they are not alphabetically sorted (happens, e.g., during regression searches). 3. Try to quickly find an arbitrary profile. 3a. Try resizing the dialog. Actual Results: 3. The list shows only 5 profiles at a time, so you have to scroll to find what you want. 3a. On Linux, the dialog is resized, but the list stays 5-line. On Windows, it is impossible to do. Expected Results: 3. The list contains more lines, because there are many profiles, and enough screen space. 3a. The list is stretched together with the dialog. PS: Don't even think of renaming this bug into "Profile Manager dialog must not be resizable on Linux", you can file another bug if you want that.
This also happens on the Windows platform with FF 220.127.116.11 and the latest trunk build. Being able to resize the dialog window would be very handy when there are numerous profiles created and you need to select a particular one which is buried down the list.
Still so with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a8pre) Gecko/2007090904 Minefield/3.0a8pre
It's a dialog, and according to common practice and platform UI guidelines dialogs are not resizeable.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WONTFIX
(In reply to Benjamin Smedberg [:bsmedberg] from comment #3) > It's a dialog, and according to common practice and platform UI guidelines > dialogs are not resizeable. I know I'm replying to a 9 year old comment, but this is still relevant (and possibly a change; I make no claims about convention at the time or official guidance from Microsoft, Apple, or any Linux organizations). With that said, I don't agree "convention of dialogs not being resizable" is a thing, and if it is then it was only intended to apply to modals with a fixed number of inputs (e.g. yes/no/cancel and a fixed message). This is modeless and has variable inputs and thus does not call for a fixed size. Here's the official MSDN document about dialogs. I'm not a Windows guy anymore but I'm pretty sure that only Message boxes are fixed - most of the "Common Dialog Boxes" are resizable... I think. https://msdn.microsoft.com/en-us/library/aa969773%28v=vs.110%29.aspx?f=255&MSPPError=-2147217396 Here's the Apple dev docs equivalent that clearly implies it is up to the programmer to make an intelligent decision about weather or not a box should be resizable (and I further infer from the language that 'make it easy for the user' and 'how much and what kind of data needs to be shown' are strong factors in deciding how to code the box): https://developer.apple.com/library/content/documentation/UserExperience/Conceptual/OSXHIGuidelines/WindowDialogs.html All of this is moot, however, in light of the fact that that box size in this case is clearly capable of being drawn at different sizes (as proven in my attachment to bug 1303078). It would seem a bit crazy to require a complete gutting of a profile or re-install of a program just to get the box to size properly where either a simple "reset to original" or user-resizable feature is a far more graceful solution. Perhaps there's a config file somewhere that stores the default size of the box and mine's simply corrupted? I could code a plugin to solve this problem and thus keep the original spirit of fixed size but let "power users" do what they want. What did Moz do when retina displays came around? That might be relevant to finding where box size is defined... anyway, happy to help solve my own problem and contribute back to the community if helpful.
You need to log in before you can comment on or make changes to this bug.