Closed Bug 940814 Opened 7 years ago Closed 7 years ago
[Australis] URLbar too wide, pushes other content out
Environment: * Linux * Screen resolution 2x 1920x1200 * Firefox window resolution 800x930 (w x h) I consider this browser window size reasonable, because * It's a good width for reading texts * I need a lot more than just 1 window on the screen Reproduction: 1. Start Firefox Australis build 2. Resize window to width 800px 3. Observer toolbar Actual result: Only: Back button, urlbar, chevron, menu button Missing are: Search field Bookmarks button Downloads button One custom button These buttons are available behind the Chevron, but that defeats the whole purpose. I can't use a search bar that is several clicks away, and ditto with bookmarks button. That makes them unusable and useless in practice. A download button that I don't see cannot alert me of an ongoing download. Expected result = result before Australis: * urlbar takes 1/2 or 2/3 of the window width * all of the above buttons and fields are visible Importance: This is major, because it cripples bookmarks to uselessness, at least in this window size. Bookmarks are a core and critical browser feature, and must work in all resolutions. If this isn't a major bug, then I don't know what ever would be. P.S. This is nothing against Australis in general.
In XUL terms: urlbar is a flex, with a min width of about 20 characters (and/or min width set by user using customizing). search bar must be a flex, with a min width of about 10 characters and max width of about 30 characters (and/or max width set by user using customizing). Within these restrictions, urlbar should be 3x larger than search bar, i.e. urlbar flex=3 searchbar flex=1.
Summary: [Australis] URLbar too wide → [Australis] URLbar too wide, pushes other content out
(In reply to Ben Bucksch (:BenB) from comment #1) > In XUL terms: > urlbar is a flex, with a min width of about 20 characters (and/or min width > set by user using customizing). > search bar must be a flex, with a min width of about 10 characters and max > width of about 30 characters (and/or max width set by user using > customizing). > Within these restrictions, urlbar should be 3x larger than search bar, i.e. > urlbar flex=3 searchbar flex=1. This is more or less what these settings are currently like, IIRC, with flex 400 vs 100, but that's not the problem here. I'm not sure why things were hidden this quickly without looking at your profile in more detail - on my machine, it happens a lot later than that. Can you reproduce this on a new profile?
Yes, same happens with a new profile. If I follow the reproduction, I get the same result. I noticed now that 810px window width or so seems to be the minimum for the search bar to show, but then bookmark button still doesn't show. I would expect the opposite: search bar is removed first. The buttons are so important, they must show even in small windows (less than 600px). It's difficult to test, because while I resize, the buttons adapt in realtime, but there is a delay of about 1s until they do, so user makes wrong conclusions about which size is needed. Implementation: I once wrong a logic for a XUL toolbar to do just that: You can define which buttons should be gone first, by assigning them an importance number. Flex elements will still shrink to their minimum size, then, if more space is needed, remove the toolbar item with the lowest important. Same backwards to grow. I think I could give you the code.
Attachment #8335284 - Attachment description: Screenshot: only urlbar and search bar, still no buttons → Screenshot, ~810px: only urlbar and search bar, still no buttons
I don't think a priority system for the overflow stuff makes sense. You might prefer to keep the buttons, other people might prefer the search bar. And no, we're not going to add options for that. The system is complex enough as it is. I can resize to ~750px without losing anything, nevermind *all* the buttons. I suspect the difference is to do with your system font size (because the address and search fields have min-widths defined in ch), in which case this is a dupe of bug 941235.
My workaround: I moved the search box to the menu bar, and used add-on "tiny menu" to shorten the menu to 3 items. (if you hide a menu item, its alt-key won't work, use alt-m then its key.) Now I can have 2 windows side by side with room to spare - even with 12pt bold system font. If you need to go narrower, add-on "Classic theme restorer" has an option to use small buttons on the navbar. Saves lots of space. (I had to add spacers on both ends of the navbar, because it squashed the ends a bit too much) Another option: add-on "toolbar buttons" has buttons for all menu items but history. Just Tiny Menu, 5 small buttons for a full menu.
The severity of this was reduced with the fix in bug 962844.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.