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




Bookmarks & History
10 years ago
a year ago


(Reporter: masayuki, Unassigned)


({polish, regression, ue})

polish, regression, ue
Bug Flags:
blocking-firefox3.5 -
blocking1.9.0.1 -
wanted1.9.0.x -

Firefox Tracking Flags

(Not tracked)



(3 attachments)

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

10 years ago
Sounds like bug 419740.
Last Resolved: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 419740

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
|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.
Resolution: DUPLICATE → ---
see also bug 387142 and bug 295223.


10 years ago
Duplicate of this bug: 437322

Comment 6

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

Flags: blocking-firefox3.1?


10 years ago
Duplicate of this bug: 422626

Comment 8

10 years ago
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.
Duplicate of this bug: 440229

Comment 10

10 years ago
Just adding my support as this is the bug I wanted to report.
Flags: blocking1.9.0.1?
Duplicate of this bug: 442525

Comment 12

9 years ago
I also am experiencing this bug.
Flags: wanted1.9.0.x?
Flags: blocking1.9.0.1?
Flags: blocking1.9.0.1-
Duplicate of this bug: 446295
Created attachment 330502 [details]
Screenshot1: undesired rectangular drag pattern in TB 3.0.1
Created attachment 330503 [details]
Screenshot2: desired oblique drag pattern (like hover in TB3.0.1)
Created attachment 330504 [details]
Screenshot3: bug: no drag to the left in TB3.0.1
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

9 years ago
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 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

9 years ago
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
Duplicate of this bug: 450687

Comment 21

9 years ago
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)


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.
(In reply to comment #21)

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
Duplicate of this bug: 453992
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.
Flags: wanted1.9.0.x? → wanted1.9.0.x-
Not going to hold the 3.1 release for this, blocking-.
Flags: blocking-firefox3.1? → blocking-firefox3.1-
Priority: -- → P3
Target Milestone: --- → Firefox 3.1

Comment 26

9 years ago
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

9 years ago
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)
Michael, since it's so simple, we'll happily take your fix.
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?
Flags: wanted-firefox3.1+
Keywords: polish, regression, ue


9 years ago
Duplicate of this bug: 451614


9 years ago
Duplicate of this bug: 438995

Comment 32

9 years ago
We may have some side effect to the following patches,
but can prevent menupopup from being closed.
(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"/>
          PlacesControllerDragHelper.currentDropTarget =;
          // check if we have a valid dropPoint
          var dropPoint = this._getDropPoint(aEvent);
          if (!dropPoint || !dropPoint.ip ||
              !PlacesControllerDragHelper.canDrop(dropPoint.ip)) {
            aEvent.dataTransfer.effectAllowed = "none";

          // 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
-            // 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;


9 years ago
Duplicate of this bug: 471226
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
Target Milestone: Firefox 3.1 → Firefox 3.2a1


9 years ago
Summary: Bookmarks submenu is closed immediately during dragging → Support diagonal dragggin through bookmarks menus (was:Bookmarks submenu is closed immediately during dragging)


9 years ago
Duplicate of this bug: 254088


9 years ago
Summary: Support diagonal dragggin through bookmarks menus (was:Bookmarks submenu is closed immediately during dragging) → Support diagonal dragging through bookmarks menus (was:Bookmarks submenu is closed immediately during dragging)
OS: Windows Vista → All
Hardware: x86 → All

Comment 36

9 years ago
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

9 years ago
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
Duplicate of this bug: 483261
too risky for 3.5, asking reevaluate as wanted 3.6
Flags: wanted-firefox3.6?
Flags: wanted-firefox3.5?
Flags: wanted-firefox3.5+
Duplicate of this bug: 488822

Comment 41

9 years ago
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

9 years ago
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:


Comment 43

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

OT: IE7??? Why not IE8

Comment 44

9 years ago
@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

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

I had originally reported this problem as and it was eventually closed as a dup of

Comment 46

9 years ago
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

9 years ago
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)


9 years ago
Duplicate of this bug: 478648


9 years ago
Duplicate of this bug: 491701

Comment 50

9 years ago
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. ). 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

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

Comment 52

9 years ago
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

9 years ago
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.


9 years ago
Flags: wanted-firefox3.5?


8 years ago
Duplicate of this bug: 503529


8 years ago
Duplicate of this bug: 459983

Comment 56

8 years ago
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

8 years ago
@#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.
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.

Component: Places → Bookmarks & History
QA Contact: places → bookmarks


7 years ago
Duplicate of this bug: 633624


6 years ago
Flags: wanted-firefox3.6?


5 years ago
Duplicate of this bug: 806195

Comment 61

5 years ago
Such an old bug :/

This addon seems to fix it:
Target Milestone: Firefox 3.6a1 → ---

Comment 62

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

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? :-)


2 years ago
Priority: P3 → --


2 years ago
Priority: -- → P4
Priority: P4 → P5
You need to log in before you can comment on or make changes to this bug.