User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1pre) Gecko/20090530 Shiretoko/3.5pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1pre) Gecko/20090530 Shiretoko/3.5pre In firefox 3.0.* when i click on a map on the bookmarks toolbar, the map opens instantly. I can hold down the mouse, move it down 1cm (or 2 or 3 for the second or 3th bookmark) and release the mouse to open the bookmark. Now with 3.5 pre, it takes about a second after holding down the mouse on a map before it opens. This breaks my daily habit of quickly opening sites in my bookmarks toolbar by about a (annoying) second. Reproducible: Always Steps to Reproduce: 1. Hold down mouse on a map on bookmark toolbar 2. Go down to and release mouse above bookmark (within one second) Actual Results: Nothing happens, bookmark map did not open Expected Results: Bookmark opened, even when clicking a bit fast.
Version: unspecified → 3.5 Branch
With 'map' I mean folder. Oops, sorry for using Dutch words.
Reporter: Please try your steps to reproduce again after starting Firefox with a new profile. You can also start Firefox in "Safe Mode": http://support.mozilla.com/en-US/kb/Safe+Mode Works For Me on Linux Shiretoko nightly build.
I can reproduce this on a new profile and safe-mode. Also got the regression range down to: Working in: firefox-3.5b5pre.en-US.win32 20090504 Broke in: firefox-3.5b5pre.en-US.win32 20090505 Might be a windows only problem. (Was also able to reproduce it on a win XP machine, originally used Vista)
For me this is something that gradually changed, also something that happened on 23 Jan 2009 seems to have played a role. Firefox 3 is really "snappy" in comparison with trunk. I think this should really be tried to repair.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: 1 second delay when clicking map at bookmarks toolbar. → 1 second delay when clicking folder on bookmarks toolbar.
wfm on mac.
Whiteboard: [polish-interactive] → [polish-interactive][TSnap]
this was changed with bug 235244, to allow dragging folders on the toolbar without having to hold down shift. The opening is a bit delayed to detect drag actions in the meanwhile. Actually that i try that, something must have regressed that since looks like i'm unable to drag folders on the toolbar, i'll have to file a bug on that.
PS: the delay is actually 500ms, not 1s
Summary: 1 second delay when clicking folder on bookmarks toolbar. → 500 ms delay when holding mouse down on folders on bookmarks toolbar before they open.
btw, if you click and move down the mouse it will be quite instant. it will delay only if you click and don't move the mouse.
Dragging without using shift would make sense, that is also how the rest of the bookmarks not directly on the bookmarks toolbar work. I think the solution for this should lay more in the fact that you can't drag a folder into itself. You can simply open a folder on mouse down, stop dragging as soon as the mouse moves in the folder, but close the folder if the mouse moves away from the current folder (and keep dragging). That also brings me to another problem, you can in fact drag a folder into itself, not directly, but you can drag it into a sub folder inside itself. Guess that's a separate issue that could use it's own bug. I open that one as soon as i got time to test it on something other then FF 3.0.10.
(In reply to comment #9) > You can simply open a folder on mouse down, stop dragging as soon as the mouse > moves in the folder, but close the folder if the mouse moves away from the > current folder (and keep dragging). that's not feasible unfortunately, would require a delayed drag start event so that it will open the folder and then if it's instead a drag it will close the folder and start dragging. We don't have a way to instantiate a delayed drag start event. so that's why this has been implemented with a small delay, but still forced to open if you move mouse down. > That also brings me to another problem, you can in fact drag a folder into > itself, not directly, but you can drag it into a sub folder inside itself. > Guess that's a separate issue that could use it's own bug. I open that one as > soon as i got time to test it on something other then FF 3.0.10. part of that could be fixed in 3.5 (so you can try that) part could be waiting for better performance fixes in the backend (faster detect of ancestors). I think we could maybe reduce the 500ms delay, but that has to be tried to see if we still act as expected.
also the delay is needed on Linux to have drag&drop of folders working at all, since there as soon as a menu opens there is no way to start a drag operation.
I don't know how or why, but using firefox-3.5pre.en-US.win32 20090606 this problem seems to be solved. It still slow when you hold down the mouse but don't move it (dragging start if you do move the mouse to the left, right or up within 500ms). However, when you move the mouse down, the bookmark folder simply opens, just like in 3.0.
(In reply to comment #12) > I don't know how or why, but using firefox-3.5pre.en-US.win32 20090606 this > problem seems to be solved. It still slow when you hold down the mouse but > don't move it (dragging start if you do move the mouse to the left, right or up > within 500ms). However, when you move the mouse down, the bookmark folder > simply opens, just like in 3.0. that's the expected behavior, indeed. We could still try to reduce the timeout, eventually.
Created attachment 384074 [details] [diff] [review] patch v1.0 we can reduce the time to 300ms. Notice menu is still instant on: - click - mousedown and move toward down. this affects only the case: - mousedown and wait, where wait will be 300ms This is needed to support drag&drop of folders on Linux, where if a folder opens it is not possible anymore to drag it... so the user has 300 ms to execute a gesture, either moving up/left/right to drag.
Assignee: nobody → mak77
Attachment #384074 - Flags: review?(dietrich)
(In reply to comment #14) > This is needed to support drag&drop of folders on Linux, where if a folder > opens it is not possible anymore to drag it... so the user has 300 ms to > execute a gesture, either moving up/left/right to drag. can we #ifdef that for linux then?
Comment on attachment 384074 [details] [diff] [review] patch v1.0 i guess i did not ifdef to avoid having different code, but is worth a try. I should also file a bug about the underlying issue on Linux if i can't find one that describes the exact issue.
Created attachment 384865 [details] [diff] [review] patch v1.1 use 300ms delay on Linux only. Fix some strict warnings and bug 500143. Dietrich, could you please check how this behaves for you on Mac? i tried it on all the 3 platforms and looks working, but my Mac-foo is low.
Attachment #384865 - Flags: review?(dietrich)
the behavior should be: mousedown: open menu instantly (different behavior from current) mousedown+move down: open menu and select mousedown+move left,right,top: drag (eventually closes menu if it opens) click: open menu instantly
Small question: Could there be a detection if the menu is going to open upwards (because the windows is at the bottom of the screen) and switch mousedown+move down with mousedown+move top behaviour?
ugh, i suppose it would be cool, but i don't know how to detect if the menu is going to be opened upwards. So, i would let that to a new bug.
Comment on attachment 384865 [details] [diff] [review] patch v1.1 wfm on mac, r=me.
Attachment #384865 - Flags: review?(dietrich) → review+
http://hg.mozilla.org/mozilla-central/rev/f0bc66c3f14f Note for QA: this doesn't apply to Linux, where there is still a small delay before a container opens on mousedown, if you don't move the mouse.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
OS: Windows Vista → All
Hardware: x86 → All
Resolution: --- → FIXED
Whiteboard: [polish-interactive][TSnap] → [polish-interactive][Tsnappiness]
Target Milestone: --- → Firefox 3.6a1
Duplicate of this bug: 501975
status1.9.2: --- → beta1-fixed
You need to log in before you can comment on or make changes to this bug.