User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-us; rv:1.9pre) Gecko/2008042806 Minefield/3.0pre Firefox/22.214.171.124 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-us; rv:1.9pre) Gecko/2008042806 Minefield/3.0pre On Drag start Bookmark item in right pane of Library window, list items shift upward so that a detailed window grows big. This becomes difficult to drop an item. Reproducible: Always Steps to Reproduce: 1.Open Library. 2.Show Bookmarks in right pane. 3.Reduce the size of the library window so that scroll bar comes out to a list item of right pane. 4.Select a item. 5 Drag start Actual Results: list items shift upward so that a detailed window grows big. Expected Results: Do not shift during drag the item.
Confirmed, jarring to say the least. Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008042806 Minefield/3.0pre Firefox/3.0 ID:2008042806
Status: UNCONFIRMED → NEW
Ever confirmed: true
Severity: minor → normal
Marco, more auto-resizing fallout. Getting tempted to just back that out in order to resolve.
Flags: blocking-firefox3? → blocking-firefox3+
thi became visible now, so i'm not sure it is completely due to auto-size of the details pane. have to take a look
i cannot reproduce the shift upwards, i only see a flicker on drop, can i have a screenshot?
Marco, the 'shift' upwards is in the "Details" pane - not the upper right pane when dragging a bookmark. Clicking a bookmark in the upper right pane opens the 'detail' for that bookmark. Now, move that bookmark - and when dropped the details pane will jump/collapse. I'm at work and can't grab screenies now, will be tomorrow at best unless you find a way to repo
Summary: Places:On Drag start Bookmark item in right pane of Library window, list items are sihfted. → On Drag start Bookmark item in right pane of Library window, list items are shifted.
i think that is not due to the autosize of the details pane, rather to the flickering (we are opening containers, i still don't have the culprit but feels like that). So this appear mostly due to bug 431140. But i see this flickering on drop, not on drag start
(In reply to comment #6) > i think that is not due to the autosize of the details pane, rather to the > flickering (we are opening containers, i still don't have the culprit but feels > like that). So this appear mostly due to bug 431140. > > But i see this flickering on drop, not on drag start > Please try this. Reproduce: 1. Add 20～more bookmarks in a folder. 2. Open Library 3. select the folder in the left pane 4. scroll list to the bottom in the right upper pane 5. dragging of last bookmark item in the right upper pane.
so, when you click on the last tree item to drag it gets selected, this way the details pane is filled, and it clearly grows... this is mostly due to 2 things: 1. if you don't have selection the details pane is shrinked, when you select something in the right pane it grows. this would be easily fixable removing the shrink in case of no selection. 2. if you have a different item selected in the left pane (for example a folder shortcut) you only see the name, then you select a bookmark in the right pane and more fields are showed (like location), so the pane grows. I fear the only way to fix this is give the details pane a fixed height based on the minimum bookmark state, this will leave a lot of unused space when selecting folder shortcuts (like bookmarks menu/toolbar) and we need to find an height valid for all OS (on windows 120px is a good value)
Created attachment 318368 [details] [diff] [review] patch - don't shrink if we don't have selection - fixed height on details pane - added a flex spacer before the more/less button to avoid button "jumps" when the user click on More, this is because with a fixed height we will have unused space in the pane, and clicking more would make the less button slide down instead or remaining under the mouse pointer. I'm using a style height in em to support high dpi views in Windows, and trying to be more cross OS. i've tested this on Windows and Ubuntu and is looking correct. asking for UI-review first, since this changes a Library heavily-used UI.
Status: NEW → ASSIGNED
Whiteboard: [has patch][needs ui-r beltzner][needs review mano]
Cannot we instead avoid selection-loss on-drop?
Comment on attachment 318368 [details] [diff] [review] patch But if we cannot, fine, r=mano.
Attachment #318368 - Flags: review?(mano) → review+
Whiteboard: [has patch][needs ui-r beltzner][needs review mano] → [has patch][needs ui-r beltzner]
(In reply to comment #10) > Cannot we instead avoid selection-loss on-drop? but the problem here is on drag start, so we should not change the selection before starting a drag. If you have an item selected and you start to drag another item, we first change selection to the dragged item, and that cause the details change
Beltzner: please, when giving ui-review (if this is ok), also set approval.
Whiteboard: [has patch][needs ui-r beltzner] → [has patch][has review][has approval]
Priority: -- → P2
Target Milestone: --- → Firefox 3
Checking in browser/components/places/content/places.js; /cvsroot/mozilla/browser/components/places/content/places.js,v <-- places.js new revision: 1.165; previous revision: 1.164 done Checking in browser/components/places/content/places.xul; /cvsroot/mozilla/browser/components/places/content/places.xul,v <-- places.xul new revision: 1.134; previous revision: 1.133 done
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Whiteboard: [has patch][has review][has approval]
Much better, Verifying fix using Vista HP SP1 and hourly build: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008050114 Minefield/3.0pre Firefox/126.96.36.199 ID:2008050114
Verified with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008050206 Minefield/3.0pre
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.