419911 - Support diagonal dragging through bookmarks menus (was:Bookmarks submenu is closed immediately during dragging)

Status: NEW

(Firefox :: Bookmarks & History, defect, P5)

Description

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I confirmed with 2008022704-trunk/WinVista.

1. Open a subfolder of bookmark toolbar or a bookmarks menu in main menu.
2. Drag an item to over a subfolder item. (the subfolder menu will be opened.)
3. Drag it to over the above/below item of the subfolder.

At that time the subfolder menu is closed immediately. Therefore, it makes difficult that dragging an item to subfolder menu. I.e., When I drag an item obliquely, the submenu is closing before I finish to drag to it. Then, the cursor exits from the parent menu, the all menus are closed.

When I'm not dragging, the subfolder menu is closed with delay.

Comment 1

[Brian Polidoro]

Sounds like bug 419740.

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

-> REOPEN

bug 419740 was fixed, but my reporting issue is still there.

I reported the menu closing delay issue.

You can test with following process:

1. Create 'A' folder to bookmarks toolbar.
2. Create 'B' folder in A folder.
3. Add Bookmark 'C' to A folder.
4. Add Bookmark 'D' to B folder.

You can see folowing menu
A
+---------+
|B       >|+----------+
|C        ||D         |
+---------++----------+

5. Drag a link from web page or a favion from the location bar to over the 'B'.

The submenu for 'B' folder is opened, you can see the 'D'.

6. Drag to over 'C'.

The submenu for 'B' folder is closed immediately.

You test the same process without drag (i.e., you only moves the mouse cursor). Then the submenu for 'B' is closed after delay.

The delay is too important for usability. Because the delay allows obliquely dragging. The current behavior requires the exact dragging course to users.

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

see also bug 387142 and bug 295223.

Comment 6

[Bryan]

I see this exact issue all the time, requesting blocking for 3.1!

~B

Comment 8

[Clifton Royston]

I just discovered this with Firefox 3.0 RC3; does not occur with 2.x

I believe there is a new bug causing this behavior.  In 3.0RC3, if a submenu of a bookmarks menu is displayed to the *LEFT* of its parent menu (e.g. due to limited screen estate to the right of FF) a very small gap will appear between the right edge of the submenu and the left edge of its parent menu.  It then becomes impossible to drag a link across this gap without exiting the active region for the parent menu, which causes both the parent menu and submenu to close.  If the submenu opens to the right of the parent menu, the submenu overlaps the parent by the same small margin and everything is fine.

Suggestion for fix: if a submenu is being displayed to the left of its parent, reverse (negate) the horizontal offset applied when it's displayed to the right, so that it overlaps the parent instead of being separated from it.

Comment 10

[Ken Runge]

Just adding my support as this is the bug I wanted to report.

Comment 12

[Paige Miller]

I also am experiencing this bug.

Comment 14

[Thomas D. (:thomas8)]

Attachment: Screenshot1: undesired rectangular drag pattern in TB 3.0.1

Comment 15

[Thomas D. (:thomas8)]

Attachment: Screenshot2: desired oblique drag pattern (like hover in TB3.0.1)

Comment 16

[Thomas D. (:thomas8)]

Attachment: Screenshot3: bug: no drag to the left in TB3.0.1

Comment 17

[Thomas D. (:thomas8)]

Starting with comment #8, this bug covers and mixes up TWO problems which IMO should be treated independently of each other:

Problem 1) (the original intention of this Bug 419911)
--> dragging of new bookmarks into nested bookmark submenus is very difficult to perform (but possible for any submenus that pop up to the right(!)). This is because Firefox forces you to drag strictly horizontally first (until mouse cursor is in the actual submenu), and then to drag strictly up/down within that submenu - like a robot (undesired drag pattern: see attachment 330502 [details]). Most people don't think like robots and therefore, they will try dragging their links straightforward to that part of the submenu where they want to drop, which means they will drag obliquely (at an angle). But as soon as your drag trail touches a millimiter of another menu of the first level, the targeted submenu will disappear. The weird thing is, if you try the the same with just hovering (instead of dragging), you will find that there is a delay before the submenu disappears and it is easily possible to quickly hover across other first level menu items while hovering at an intuitive angle right into somewhere in the middle of the open submenu - you just have to reach there before the submenu disappears. The request is to have exactly that more tolerant behaviour for dragging, which would make the actual dragging movement so much smoother than it is now (for desired dragging path, see attachment 330503 [details]). Strictly speaking, this is a usability issue 

Problem 2) (first mentioned in comment #8)
--> dragging of new bookmarks into nested bookmark submenus is IMPOSSIBLE as soon as submenus pop up on the left(!) of the menu due to lack of screen space on the right.
This is a proper BUG, which is likely to be fixed rather quickly.

I think it would be best to split the two aspects of this bug into two sperate bugs:
- this one, bug 419911, could then serve as an RFE calling for a smoother dragging experience (intuitive, oqlique dragging)
- one of the duplicates of this bug, e.g. bug 446295, could be used to collect duplicates and comments on the real bug that left-dragging into submenus is NOT possible at all, regardless of your mouse pointer skills.
Duplicates so far are looking into both problems, which makes the whole affair somewhat confusing.

Comment 18

[Miles]

If drag from location bar to bookmarks/bookmarks cannot drop in 3rd drop down window even if dragged to the right in a perfectly straight line then perfectly straight up to open a 3rd folder.

This necessitates use of the sidebar which I dislike.  Attempted to revert to 2.0.0.14 which was on the computer, but somehow was replaced with update 3.0 to 3.01, so am now stuck with the dumb sidebar (or starting over with FX2!)

Comment 19

[Michael Lueck]

Sounds like the same problem I opened here: 450687.

Thus, also affects the official Mozilla build for Linux. Running Ubuntu 8.04 and using the UbuntuZilla installer to install the official build from mozilla.org.

Comment 21

[somhairle2]

I have this same problem on vista x64/FF 3.0.1

this issue really annoys me as i have to use the "organize bookmarks" to get things where i want them (a feature i ONLY use when spring cleaning my bookmarks)

PLEASE FIX IT SOMEBODY!?

as a side note... don't know if its possible to implement, what about having an option to "ctrl + drag" a link from the address bar to the bookmarks toolbar which automatically opens the 'properties' dialog so that you can edit the name and maybe add a keyword or two. I know I do this for nearly all my bookmarks as it is.

Comment 22

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

(In reply to comment #21)
> PLEASE FIX IT SOMEBODY!?

Please don't spam, this comments does not help fixing an issue. Thank you

> as a side note... don't know if its possible to implement, what about having an
> option to "ctrl + drag" a link from the address bar to the bookmarks toolbar
> which automatically opens the 'properties' dialog so that you can edit the name
> and maybe add a keyword or two. I know I do this for nearly all my bookmarks as
> it is.

I think this is extension related, however you should try opening an enhancement bug for this kind of request

Comment 24

[Samuel Sidler (old account; do not CC)]

Doesn't really meet the "wanted" criteria (security, stability, regression from maintenance release) for 1.9.0.x. However, we'll look at a reviewed and baked patch.

Comment 25

[Dietrich Ayala (:dietrich)]

Not going to hold the 3.1 release for this, blocking-.

Comment 26

[Miles]

Guess I'll simply return to using 2.x until you people decide to fix this huge flaw. (saving bookmarks in 3.x has worn me down while waiting for it to be fixed for 3.1.  Please let me know if you ever do something about this and I'll try whatever version that is in the future.)

Comment 27

[Michael Lueck]

I am sorry to see this FF 3.x specific problem shoved to the back burner yet again.

It was not a problem with official builds of FF 2.x, it is a problem with FF 3.x... what can be so complicated to see "what went wrong" between 2.x and 3.x and FIX IT! (shrug)

Comment 28

[Mike Beltzner [:beltzner, not reading bugmail]]

Michael, since it's so simple, we'll happily take your fix.

Comment 29

[Mike Beltzner [:beltzner, not reading bugmail]]

Snarking aside, Dietrich, this is a pretty big usability issue, so if we have time before we ship we should definitely see if we can get attention on it.

Ria: do we have a regression window? Same as bug 460869 comment 0, which implicates bug 389661?

Comment 32

[Alice0775 White]

We may have some side effect to the following patches,
but can prevent menupopup from being closed.
\places\menu.xml, 
(Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081124 Minefield/3.1b2pre ID:20081124170715)

      <method name="onDragOver">
        <parameter name="aEvent"/>
        <parameter name="aFlavour"/>
        <parameter name="aDragSession"/>
        <body><![CDATA[
          PlacesControllerDragHelper.currentDropTarget = aEvent.target;
          // check if we have a valid dropPoint
          var dropPoint = this._getDropPoint(aEvent);
          if (!dropPoint || !dropPoint.ip ||
              !PlacesControllerDragHelper.canDrop(dropPoint.ip)) {
            aEvent.dataTransfer.effectAllowed = "none";
            return;
          }

          // add a dragover attribute to this popup
          this.setAttribute("dragover", "true");

          if (dropPoint.folderNode) {
            // We are dragging over a folder
            // _overFolder should take the care of opening it on a timer
-            if (this._overFolder.node &&
-                this._overFolder.node != dropPoint.folderNode) {
-              // we are dragging over a new folder, let's clear old values
-              this._overFolder.clear();
-            }
            if (!this._overFolder.node) {
              this._overFolder.node = dropPoint.folderNode;
              // create the timer to open this folder
              this._overFolder.openTimer = this._overFolder
                                               .setTimer(this._overFolder.hoverTime);
            }
-            // since we are dropping into a folder set the corresponding style
-            dropPoint.folderNode.setAttribute("_moz-menuactive", true);
          }
-          else {
-            // We are not dragging over a folder
-            // Clear out old _overFolder information
-            this._overFolder.clear();
-          }

          // Autoscroll the popup strip if we drag over the scroll buttons
          var anonid = aEvent.originalTarget.getAttribute('anonid');
          var scrollDir = anonid == "scrollbutton-up" ? -1 :
                          anonid == "scrollbutton-down" ? 1 : 0;

Comment 34

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

this requires revising the timer and draggign code in places views, so most likely not going to make 3.1 due to high risk of regressions

Comment 36

[Jim Scott]

Also experiencing this issue on 3.0.6 (Windows XP MCE 2005 SP2).

I started over on the Firefox Support Forum (285845?) and Cor-el pointed out the 1 pixel gap which makes sense given description of failure mode above.

I see we're discussing timers and dragging code modifications. I am curious (and perhaps overlooked the reason) as to why we are not just changing the menu / sub-menu display horizontal offset; ie, reversing it [ref comment #8 above] or modifying it appropriately when applied to the opposite side so the gap no longer exists effectively eliminating the problem because the existing D&D code apparently works fine if there is no gap.

BTW, thanks in advance for the efforts in fixing this. I D&D links all the time (bookmarks file > 2.6MB) and this has been a REAL pain.  :-)

Comment 37

[Luxthor]

I have simple solution before you find the way how to fix bug, just add new option 'Add Bookmark...' in Bookmark Toolbar right click Menu, option will do same thing like 'New Bookmark...' except they will copy URL link and site title from Navigation Toolbar. There will be no need for annoying copy/paste or dealing with bugged drag and drop.

New Bookmark Toolbar right click Menu(specific section) should look like:
...
----------------
Add Bookmark...
New Bookmark...
New Folder ...
New Separator
----------------
...

Comment 39

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

too risky for 3.5, asking reevaluate as wanted 3.6

Comment 41

[Valmir]

Why this is taking so long to be fixed? The first post is from 2008-02-27, more than one year ago.

This is like those companies that follows boring process such as CMMI, RUP, etc. Too much blah blah blah end no action. 

Please could someone fix this flaw or it's needed all users migrate to Internet Explorer 7

Comment 42

[Jim Scott]

Valmir, you're in the wrong sandbox. This area is for the cats sharing info on how to fix the problem. The rest of us cats only get to watch the fun. ;-)

Seriously, the formal guidelines are here:
  https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

ciao

Comment 43

[somhairle2]

hey Valmir, it seems to be working fine for me in version 3.0.9

OT: IE7??? Why not IE8

Comment 44

[Blake]

@Comment #43:

The bug still exists from "Screenshot3: bug: no drag to the left in TB3.0.1" in v3.0.9; and possibly so do the others seen in the screen shots.

Comment 45

[Andy Wozniak]

I can confirm that this bug is still present in 3.0.9 under winxp

I had originally reported this problem as https://bugzilla.mozilla.org/show_bug.cgi?id=438995 and it was eventually closed as a dup of https://bugzilla.mozilla.org/show_bug.cgi?id=419911

Comment 46

[Valmir]

Ciao Jim, come và? I'm sorry. I got a bad day today. But I'd love to see this problem fixed ASAP.

Samuel, I'm running WinXp sp3 and FF 3.0.9. The problem persists.

Comment 47

[somhairle2]

I've been away. Indeed the "drag to the left" bug still exists (Just confirmed on both XP 32-bit and Vista 64-bit). I was previously referring to the thread title only. 

Although it is 'possible', the  bug is more apparent on folders with just one link inside (dragging a second link is next to impossible). I do find that if you aim for the very top of the folder you are dragging to, it works 1 out of 5 times (which isn't acceptable)

Comment 50

[Axel Boldt]

As the duplicates Bug 478648 and Bug 491701 point out, the bug is particularly severe when dealing with bookmark subfolders that open to the left (see e.g. http://math-www.uni-paderborn.de/~axel/dragdropbug.gif ). It is virtually impossible to drag bookmarks into such subfolders. There is a tiny space between the folder and the subfolder; when trying to drag a bookmark into the subfolder, the subfolder will close first (unless one is fast enough).

(3.0.10 on Win XP)

Comment 51

[Miles]

And I have the same difficulty with bookmark sub-folders opening to the right. 3.0.10, WinXP Home, SP2.

Comment 52

[Axel Boldt]

Drag-and-drop into bookmark sub-folders opening to the right is possible as long as the user avoids "diagonal" dragging and drags horizontally on the line of the parent folder. Drag-and-drop into sub-folders opening to the left is virtually impossible, because of the gap between the two menus. 

It appears that both issues could be solved by using a small timeout before closing sub-folders when dragging, just like the timeout that's currently being used before closing sub-folders when moving around in the folder hierarchy without dragging.

Comment 53

[Axel Boldt]

It is incorrect to mark Bug 254088 as a duplicate of this bug. That one is about faulty behavior when opening bookmark folders; this one is about faulty behavior when dragging bookmarks into folders.

Comment 56

[Jerry]

Was going to report this but see that it is already here.  Having this problem in Firefox 3.5.3.  If the bookmark folder opens/expands on the right then I can drag into it but if it expands on the left I can not.

Comment 57

[Jim Scott]

@#53: hallo, Axel. I think Marco was just consolidating bugs; the assumption being that both likely have a common cure. Let us see what they come up with.

@#56: Jerry, if one lines up the cursor with the parent item and then carefully scoots very quickly straight across to the open sub-menu (WITHOUT overshooting the sub-menu boundary), one is usually successful. Annoyed, but successful. :-)

Also, there is an alternate: the star icon (right end of the the address box) can be used to add / modify bookmarks. One click on a white star adds the bookmark to the unsorted bookmark list and turns the star gold. One click on a gold star opens that bookmark's property window. My only complaint is that the folder lists aren't expandable and IMHO are too short (ie, it takes a lot of scrolling to get the job done).

But now we're way off the purpose for this thread ... sorry.

Comment 58

[Gervase Markham [:gerv]]

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

Comment 61

[klonos]

Such an old bug :/

This addon seems to fix it: https://addons.mozilla.org/en-US/firefox/addon/bug419911-diagonal-dragging/

Comment 62

[Kaj]

This is so old and annoying bug and no one can fix it? It is still a bug in version 31.0!!! :-(

Details:
Missing the 'safety-delay' when moving a tab page (left mouse click and hold on that tab page when cursor and tab page is moving) to a sub folder within a bookmark. When accessing a sub menu WITHOUT moving a tab page (only clicking the bookmark to access a sub menu), when cursor for a short time is slipping a little bit outside the menu text line (which leads to the sub menu), the popped up sub menu will still hold open because of the needed delay to hold the focus on the sub menu. When moving a web site or a tab page to a sub folder, there is no delay outside the menu text line and the sub menu immediately disappear (and if outside the bookmark menu, also the bookmark menu i disappearing). It's not depending on which sides the curser moves from. I have also deactivated all the add-ons with the same results.

Can this please be fixed once for all? :-)

Comment 63

[pkrbt46]

The add-on mentioned by klonos above has stopped working since Firefox 57, since it's a legacy add-on, but maybe the code posted above by Alice could be directly integrated into Firefox?

Comment 65

[Hagen Wende]

I also find this very annoying, when you sort your bookmarks, and it is still there in 84.0.2
Does anyone have work around or fix?

Comment 66

[Jim Scott]

I see the gap between menu and submenu is mentioned in several places by way of complaint ... but not in any posts regarding possible fixes or cures (or perhaps I missed it). Is the gap a result of menus / submenus being fixed in width (thus a gap may occur depending on the display if use)? It seems that when there is no gap (i.e., at least 1 pixel overlap) that the problem does not manifest. A visual check for gap is vague because most displays cannot discern a one pixel gap. By way of reference, menus / submenus that open in my Chrome-de-jour vary in width as needed, and have a 4-5 pixel overlap; and I don't have any dragging problems. Apologies, I cannot speak to Firefox or Internet Exploder.

Comment 68

[S. Jones]

I don't normally visit Bugzilla but I came here because I'm just so frustrated with this absurd bug never getting fixed. Year after year, Mozilla continues to add fancy new features to Firefox, but doesn't bother to fix the most basic interface problems like this? It defies belief.

Just to point out the exact problem (Steps to reproduce the problem:)

1. Click any folder in the Bookmarks bar
2. Move the cursor down to a sub-folder and its contents will appear to the side.
3. Move the cursor ''diagonally ''down into a lower part of the sub-folder, and you can successfully navigate into it. This is because there is a delay before the subfolder disappears.
4. However, if you repeat the above process ''while dragging a bookmark'', there is no delay before the subfolder disappears, this makes it incredibly awkward and difficult to organize bookmarks in the Bookmarks bar.

A related problem is that when you create a new folder or rename something, your entire folder trail disappear and you have to go right back to the top and try and find where you were again. So if you're renaming and deleting a lot of folders, this makes the Bookmarks Toolbar impossible to work with.

With all due respect, these bugs make Firefox look sloppy and amateurish and I don't know how they ever made it into the final version, let alone going unfixed for nearly 2 decades.

Comment 69

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

I think the Proton design in Firefx 89 has pretty much made this bug very rare or not applicable, since now submenus overlap the parent menu. This should basically not happen anymore in the most used views.
Additionally, we honestly don't think anymore menus are the right UI to do anything serious with bookmarks, and my personal opinion is that Firefox should completely stop using menus for bookmarks. Don't know if it's going to happen, but we're unlikely to spend more time on optimizing a menu view that, by its own nature, is not adapt for a bookmarks hierarchy.

Comment 70

[S. Jones]

Firefx 89 has pretty much made this bug very rare or not applicable, since now submenus overlap the parent menu

The fact that submenus overlap the parent menu is irrelevant. If you're dragging a bookmark down to the bottom of the submenu, your hand will naturally move the cursor diagonally down, causing the submenu to disappear. (Note that this bug ONLY occurs when you're dragging something. If you're just browsing the folder, the bug doesn't occur.)

we honestly don't think anymore menus are the right UI to do anything serious with bookmarks

What other way is there to bookmark tabs other than dragging them directly into the Bookmarks Toolbar. This requires ONE CLICK and takes about 1 second.

The only alternative method to save bookmarks (that I am aware of) is to:

1. First press Cltr+D to save it
2. Then click Enter to save
3. Then press Ctrl+Shift+o to bring up the Library (forcing you to take your hand off the mouse)
4. Then scroll down to "Other Bookmarks"
5. Then click on "Other Bookmarks"
6. Then click on the added bookmark
7. Then Ctrl+x to cut it
8. Then scroll up to the Bookmarks Toolbar
9. Then click on the Bookmarks Toolbar
10. Then navigate to the destination folder, requiring several double clicks. (This is made even more difficult because in Library view, the folders have no fixed physical location, but in the Bookmarks Toolbar, everything is in a fixed location across the screen making it easy to remember where things are.)
11. Then Ctrl+V to paste it into position
12. Then Ctrl+W to close the Library

That's about 21 clicks and key presses in total, and a lot of work. Surely Firefox users are not expected to do all this every single time we want to save a bookmark? I save dozens of bookmarks every day so I need the fastest possible method, and what could be faster than simply dragging it into the bookmark bar?

And I know that Mozilla is aiming for a clean, elegant interface so I'm sure that users are not expected to have the Bookmarks sidebar constantly on screen, taking up space and looking messy? Plus items in the Bookmarks sidebar don't have a fixed physical location so they're much harder to find quickly. I know of no quicker way of saving bookmarks than dragging them into the Bookmarks Toolbar, correct me if I'm wrong.

Comment 71

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

(In reply to L. James from comment #70)

The fact that submenus overlap the parent menu is irrelevant. If you're dragging a bookmark down to the bottom of the submenu, your hand will naturally move the cursor diagonally down, causing the submenu to disappear.

Thank you for pointing that out, clearly I was wrong, and this is still annoying.

What other way is there to bookmark tabs other than dragging them directly into the Bookmarks Toolbar. This requires ONE CLICK and takes about 1 second.

I didn't say that the toolbar should go away, I was just speaking about the fact nested menus are not a good UI for a hierarchy of bookmarks. I don't know what's the perfect solution, but the bookmarks sidebar, while not perfect, is a much nicer view to manage and use bookmarks than multiple nested submenus.
I think the toolbar has its own benefits, but maybe it should be managed differently than just copying part of a hierarchy, more like Top Sites where you can pin/unpin to the toolbar (note, I'm just expressing thoughts, there's no plan to do anything atm).

That's about 21 clicks and key presses in total, and a lot of work. Surely Firefox users are not expected to do all this every single time we want to save a bookmark? I save dozens of bookmarks every day so I need the fastest possible method, and what could be faster than simply dragging it into the bookmark bar?

Fwiw, the star panel remembers the last used folder and defaults to the toolbar now, so a single click on the star may be enough. There's bug 1412263 that if implemented would allow to fix the default folder to a given destination.

Comment 72

[S. Jones]

the bookmarks sidebar, while not perfect, is a much nicer view to manage and use bookmarks than multiple nested submenus.

I do know what you mean, but personally I much prefer the Bookmarks Toolbar, for several reasons:

1. The Sidebar causes a combination of truncated folder titles and ugly blank space beside shorter titles. When you go in a folder, the actual bookmarks are heavily truncated. With the Bookmarks Toolbar, you see all the folder titles with no wasted space, and plenty of the bookmark titles.
2. When you open a folder in the Sidebar, you see far less items than what you do in the Toolbar, making it feel cramped and claustrophobic. And if the folder you're opening isn't near the top of the screen, you see very little of its contents when you open it.
3. The Sidebar requires clicking subfolders to open. The Toolbar opens subfolders when you hover on them, which feels more open and welcoming.
4. If you start expanding folders in the Sidebar, you have to "tidy up" afterwards to get collapse everything back to normal. The Toolbar never needs tidying, which is less stressful.
5. A major factor is, as I said, the folders in the Sidebar have no fixed location, which makes you feel disoriented. In my Bookmarks Toolbar I have 13 main folders going across the screen and that is my portal to everything I do online. I know where everything is and it never moves. But when I use the Sidebar, I feel lost. This is because the Toolbar presents the folder structure in two dimensions (x and y), while the Sidebar crams the entire hierarchy into just one dimension (y).
6. I find it deeply irritating that the Sidebar shows the Bookmarks Toolbar, Bookmarks Menu, and Other Bookmarks. I have no use or interest in the two other locations and don't want to see these locations appear anywhere ever. Having these other locations only makes it more disorienting and confusing. Plus it adds an extra level of indentation to the sidebar which wastes yet more space.
7. I think the top of the screen should be the "starting place".
8. Above all else, I do not want to have the Bookmarks Sidebar open. I have no room for it as that's where my tabs go. (I use the Vertical Tabs Reloaded extension as I strongly believe that presenting tabs horizontally totally wrong.)

For me, the only advantages the Sidebar has over the Toolbar are:

1. Having a scrollbar is nice, not just for its functionality, but it gives a visual cue of the folder size. I would love to see scrollbars in the Bookmarks Toolbar.
2. The Sidebar is nice and solid and doesn't disappear whenever you do anything like rename or create a folder. I wish the Bookmarks Toolbar didn't do this!

Fwiw, the star panel remembers the last used folder

Having a default save location is of no interest to me as I regularly save bookmarks into dozens of different places. For example: "Articles to read", "Videos to watch", "Things to buy", "Discussions", "Utilities", etc each with many sub-categories in folders. I find that having more folders maximizes my productivity.

I don't know what's the perfect solution

I have some thoughts on a perfect solution: (Something of a fantasy, but you may find it interesting.)

1. The Bookmarks Toolbar is a little taller, perhaps it expands vertically when you roll over it, because it's important.
2. Folders can be custom colored, to help better remember contents
3. When there aren't many folders, they automatically expand to be wider. As you approach filling the screen, they start getting smaller automatically to fit more on.
4. If you fill the width of the screen, you have arrows to flip between pages. I prefer flipping to scrolling.
5. Instead of a folders being an icon with text beside, folders are a rounded rectangle with text inside
6. Instead of being just a vertical list, folders with many items have columns, similar to Windows' List view mode.
7. These folder content windows don't connect directly to the Toolbar, they are more like floating dialogs, and they're centered horizontally.
8. When you first click a folder on the Toolbar, it animates downward to show the folder contents. When you move left and right between folders, the window animates resizing, then when you leave the Toolbar Menu, it animates going back up.
9. Folder content windows have a 'pin' in the corner so you can keep them from disappearing. You can also drag them around
10. At all times, the Bookmarks Toolbar has a small folder named 'Tabs'. Click this to show all your open tabs, in just the same style as the bookmark folders. Items can be dragged between tabs and bookmarks, either to open bookmarks, or to bookmark tabs.
11. You can also directly Shift-click on multiple tabs and drag them straight into any Bookmarks Toolbar dialog, this will close the tabs. Holding shift while dragging will keep the tabs open.
12. Browser window could also be darkened while using the Toolbar, both to give clarity to what you're doing and to signal that the Toolbar has the focus.

If interested, I would be more than happy to illustrate my idea above, perhaps in a video.

Comment 74

[L.I.A.R.]

(In reply to Marco Bonardo [:mak] from comment #69)

I think the Proton design in Firefx 89 has pretty much made this bug very rare or not applicable, since now submenus overlap the parent menu. This should basically not happen anymore in the most used views.
Additionally, we honestly don't think anymore menus are the right UI to do anything serious with bookmarks, and my personal opinion is that Firefox should completely stop using menus for bookmarks. Don't know if it's going to happen, but we're unlikely to spend more time on optimizing a menu view that, by its own nature, is not adapt for a bookmarks hierarchy.

On the contrary, I had no problem with the old UI, and with the new one it is PitA to drag and drop a tab/lock into a subdir of the Bookmarks toolbar.
See my entry here: https://bugzilla.mozilla.org/show_bug.cgi?id=1739981

Comment 75

[L.I.A.R.]

New video with FF 97:
https://drop.infini.fr/r/4BmMoXaKqv#0dJp3FStop1o9INyps01b2KBU70Xp/vpxSmKubStkYY=
It is simply impossible to drag a tab to a subdir of the ">>" symbol on the Bookmark Toolbar.
PS: the video captures the main window of FF, so unfortunately the menu that opens when clicking/moving above ">>" is not shown :[ but I can confirm it is displayed when the tab is dragged on top of it, BUT it disappears AS SOON AS the tab is moved again... Thus making simply impossible to bookmark the tab in a subdirectory of the Bookmark toolbar

Comment 76

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

(In reply to L.I.A.R. from comment #75)

It is simply impossible to drag a tab to a subdir of the ">>" symbol on the Bookmark Toolbar.

That is not what this bug is about and should have not been duplicated here. I'll reopen the bug.

Comment 77

[Nom]

It seems like this issue may be the same as one i just submitted, https://bugzilla.mozilla.org/show_bug.cgi?id=1784956

I hesitated to add to this bug, rather submitting a new one, for two reasons:

1. this bug is not that descriptive, has no obvious video reproduction attached, and seems to reference diagonal whereas the reproduction seems to clearly be related to a gap / padding / margin, nothing to do with any less-than-horizontal movement. Although moving diagonal might be a further improvement, it's not the core issue.
2. it's 15 years old (!) wow, time flies :) But in order to understand the bug, you need to read 15 years of comments? This probably isn't helpful :)
3. the title change to diagonal drag does not match what I see as a user, even if technically somehow that's related and my assumption in #1 is wrong.

If somehow this is the same issue - for the love of asdf please move my attached gif into this issue, and mark many more of the comments off topic. Thanks for your help!

Comment 78

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 19 duplicates, 33 votes and 51 CCs.
:mak, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 79

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Comment 80

[Intermittent Failures Robot]

1 failures in 3510 pushes (0.0 failures/push) were associated with this bug in the last 7 days.

Repository breakdown:

• autoland: 1

Platform and build breakdown:

• linux1804-64-qr: 1
  • debug: 1

For more details, see:
https://treeherder.mozilla.org/intermittent-failures/bugdetails?bug=419911&startday=2022-12-05&endday=2022-12-11&tree=all