Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b3pre) Gecko/2007122604 Minefield/3.0b3pre The current initial height of the details deck within the Library shows the vertical scrollbar and only half of the description. So the user will change its height definitely. We should use a good initial height which also covers the more details view of bookmarks. Currently we are using a height of 85px which results in a vertical scrollbar. With a height of 250px which is a bit more as the half height of the infoPanel all information can be shown without any scrollbar. This can be seen on different OS. I tried to find this height within the different themes but wasn't able to locate it. Where this height is computed?
Maybe the vertical scroll bar should only be shown inside the "Description" field and maybe also in the "Name" field. Then the height of the bottom panel is not an issue anymore and it saves space.
Created attachment 294729 [details] Possible initial segmention This issue persists. Just select a bookmark and not a folder. In that case we even need more space. Due to we don't ship too many bookmarks with a new profile we have a lot of space above the details deck which ends up in a empty area. So why we should have such a small details deck where the user also have to scroll? I attached a screen shot which shows a possible sectioning.
Ideally the height should increase to show everything when the user clicks the "more" progressive disclosure control. Is this possible? If not, we probably should set the height to be enough so we don't pick up a scroll bar by default on expansion.
In that case we should use a height of 230px. If anyone can tell me where we define the height I could come up with a patch. I cannot find the definition.
Mano, any chance to get this fixed? Sadly, I cannot see a starting point where to start.
Severity: minor → normal
Marco, do you know where the initial size of the details deck is located or computed?
i can't see it defined anywhere, should be in places.xul <hbox persist="height" id="infoPane">
Marco, that is what I already found. After you resize the infoPane the new size is written out into localstore.rdf and will be chosen when you reopen the Library. But where we have to set the initial height?
if you simply want to set a fixed height you can do there adding the height attribute
(In reply to comment #10) > if you simply want to set a fixed height you can do there adding the height > attribute But doesn't this ignore the already stored height of the last adjustment? I really would like to see this fixed.
(In reply to comment #11) > But doesn't this ignore the already stored height of the last adjustment? No, the stored hight should take precedence over the default height.
Marko, so the height is now auto-computed? This bug will be in conflict with bug 428020.
=> wontfix, bug 403140 makes the infoPane auto-size, thank you
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WONTFIX
Status: RESOLVED → VERIFIED
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h". In Thunderbird 3.0b, you do that as follows: Tools | Message Filters Make sure the correct account is selected. Click "New" Conditions: Body contains places-to-b-and-h Change the action to "Delete Message". Select "Manually Run" from the dropdown at the top. Click OK. Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter. Gerv
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
You need to log in before you can comment on or make changes to this bug.