Closed Bug 483261 Opened 14 years ago Closed 14 years ago
Drag and drop bookmarks in menus on Linux is tricky, drop on containers area is too narrow
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3) Gecko/20090313 Shiretoko/3.1b3 Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3) Gecko/20090313 Shiretoko/3.1b3 Bookmarks can be moved around the bookmark menu by dragging and dropping the items with the mouse. A small black horizontal bar will show the target place where the bookmark will be placed. The bookmarks can even be dragged into submenus. In this new version of beta 3, it seems like the drag-and-drop to submenu interface has changed, to be less usable. Unless the mouse is navigated directly along the name of the submenu, then the entire Bookmarks menu is closed. Seems to me that previous versions were more flexible in how the mouse to entered the submenu, without closing the whole menu. Reproducible: Always Steps to Reproduce: 1.Open Bookmarks menu, with mouse. 2.Click and hold one of the existing bookmarks. 3.Hover mouse over a submenu, in the Bookmarks menu. 4.Attempt to move the dragged bookmark into the submenu. Actual Results: Bookmark menu closes. User still has bookmark selected in mouse cursor. Expected Results: Bookmark menu and submenu should remain open, to allow user to move the bookmark.
(In reply to comment #0) Correction: Expected Results: Bookmark menu should remain open, with the submenu being closed. This is how the Bookmarks menu works in 3.0.6 version.
Just wanted to add that I also see this bug when running an updated 1386 Fedora 10 install. User agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3) Gecko/20090305 Firefox/3.1b3
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
Marco, I've duped this bug yesterday against bug 419911 but there seems to be a little difference. This one is really about the bookmark menu itself and not the sub-folders. Sorry for the confusion. This is a regression against FF3.0.x, which should be handled separately?
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
would be if i could reproduce, i just tried in ubuntu and the only issue i see is that you have to d&d perfectly horizontal, if you go out of the space that is considered the folder everything closes. This space is small, smaller than what i would expect, but the code is shared with windows and mac, so could be there's something different to be considered for the pixel calculation on linux.
i can probably enhance this a bit, there's a 3 px error in the over calculation, that i can correct, and i would change the threshold from 25%/75% to 20%/80%.
Assignee: nobody → mak77
Status: NEW → ASSIGNED
Just to be really, really clear here -- The bug is that the entire Bookmark menu closes, instead of just the submenu. There is already a bug 419911 about the pixel size available of moving the mouse into the submenu.
this adds about 4px to the area of the node that we consider to "drop inside", should allow a slightly better behavior. Won't make d&d perfect though, since user has still to drag horizontally, and due to the position of the mouse we usually tend to drag slightly toward down, for that we need bug 419911.
Attachment #367580 - Flags: review?(dietrich)
Comment on attachment 367580 [details] [diff] [review] patch v1.0 r=me
Attachment #367580 - Flags: review?(dietrich) → review+
OS: All → Linux
Hardware: All → x86
Summary: Drag and drop bookmarks - moving bookmark into submenu closes menu → Drag and drop bookmarks in menus on Linux is tricky, drop on containers area is too narrow.
Assignee: mak77 → nobody
Component: Menus → Places
QA Contact: menus → places
Status: ASSIGNED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.2a1
Comment on attachment 367580 [details] [diff] [review] patch v1.0 asking approval, this is a minor fix that allows for easier D&D on Linux menupopups. Risk is low.
Attachment #367580 - Flags: approval1.9.1?
Comment on attachment 367580 [details] [diff] [review] patch v1.0 a191=beltzner
Attachment #367580 - Flags: approval1.9.1? → approval1.9.1+
Matthew, can you please check with the latest nightly build of Shiretoko if the problem you reported in comment 0 is fixed now? Thanks.
Not fixed. Sorry I have been unable to be more clear about these details. In the nightly, the entire bookmark menu still closes. In 3.0.8, just the bookmark's submenu closes, leaving the bookmark menu open. Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2a1pre) Gecko/20090408 Minefield/3.6a1pre
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
as i said in comment 8 this fix did not intend to make D&D perfect, instead it made the situation better, as i could test on Ubuntu. When you drag ensure you move the mouse "almost" horizontally while you are on the container. "almost" now is less strict than before.
your original report says "Unless the mouse is navigated directly along the name of the submenu", so that's finally bug 419911, i don't think there's anything more we can do here.
after a clarification on IRC, this bug covers a real bug in linux drop space calculation, Matthew can confirm it is somehow better now. On the other side bug 419911 makes the drag action be quite "robot-like", so the fact menus close is not fixed, is wanted but a more natural diagonal drag would largely help any user. We should simply fix bug 419911 asap, then backport the fix to 3.5 branch if possible.
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Based on out discussion, I can verify this fix of drop space calculation. It is much easier to drag and drop bookmarks into sub-menus now. As for my complaints of the entire menu closing, it is my understanding that this part of a larger user interface design.
Status: RESOLVED → VERIFIED
Matthew, which version have you used to verify this fix? If it was Shiretoko we have to replace fixed1.9.1 with verified1.9.1 in the keyword textbox. If you have tested with Minefield we have to set the bug status to verified. I believe you tested with Shiretoko only? Then could you please also run a test with a Minefield build please?
#20 used the version referenced in comment #15 I believe that it is the nightly minefield
Ok, would you mind running it with a Shiretoko build too? You can find the latest one here: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/04/2009-04-09-03-mozilla-1.9.1/ That would be fantastic! Thanks Matthew.
#22 sorry - no 64-bit linux build there - do not have time to put together a development environment to compile one this weekend, either...
Oh, sorry. Haven't seen that you are using 64bit. This link is better: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/04/2009-04-09-05-mozilla-1.9.1/
verified with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b4pre) Gecko/20090415 Shiretoko/3.5b4pre
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.