495675 - 500 ms delay when holding mouse down on folders on bookmarks toolbar before they open.

Status: RESOLVED FIXED

(Firefox :: Bookmarks & History, defect)

Description

[Dorus Peelen]

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.

Comment 1

[Dorus Peelen]

With 'map' I mean folder. Oops, sorry for using Dutch words.

Comment 2

[David Dahl :ddahl]

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.

Comment 3

[Dorus Peelen]

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)

Comment 4

[Ria Klaassen (not reading all bugmail)]

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.

Comment 5

[Dietrich Ayala (:dietrich)]

wfm on mac.

Comment 6

[Marco Bonardo [:mak]]

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.

Comment 7

[Marco Bonardo [:mak]]

PS: the delay is actually 500ms, not 1s

Comment 8

[Marco Bonardo [:mak]]

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.

Comment 9

[Dorus Peelen]

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.

Comment 10

[Marco Bonardo [:mak]]

(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.

Comment 11

[Marco Bonardo [:mak]]

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.

Comment 12

[Dorus Peelen]

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.

Comment 13

[Marco Bonardo [:mak]]

(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.

Comment 14

[Marco Bonardo [:mak]]

Attachment: 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.

Comment 15

[Dietrich Ayala (: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 16

[Marco Bonardo [:mak]]

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.

Comment 17

[Marco Bonardo [:mak]]

filed bug 500081 about drag&drop issue.

Comment 18

[Marco Bonardo [:mak]]

Attachment: 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.

Comment 19

[Marco Bonardo [:mak]]

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

Comment 20

[Dorus Peelen]

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?

Comment 21

[Marco Bonardo [:mak]]

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 22

[Dietrich Ayala (:dietrich)]

Comment on attachment 384865 [details] [diff] [review]
patch v1.1

wfm on mac, r=me.

Comment 23

[Marco Bonardo [:mak]]

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.