Bug 1863845 Comment 27 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

I can confirm the problem (Windows 10, 64bit).

Maybe the description is not sufficient to reproduce the bug. so I'll try to give a more detailed analysis here.

In Windows Explorer the user experience for Drag & Drop is as follows:
--
1. Select a object with the mouse and hold the mouse button pressed.
2. Move the object over the desired folder in the folder tree.

Now following can happen:

**You release the mouse button "< X msec".**

3. The object is placed in the folder without opening it.

**You keep the mouse button pressed "> X msec":**

3. The folder will be opened.
4. You can move the mouse over the sub-folder and release the mouse button to place the object there.

In Thunderbird the user experience is:
--

When moving a **message** to a folder:

Thunderbird behaves like expected in *most* cases. But I have noticed that *sometimes* there is no response. Even if the mouse pointer is held over the folder for a long time, it does not open. If I delete the sub-folder and create it again, the parent folder opens. -> Maybe a different bug, I could not find a way to reproduce it reliable.

When moving a **folder** in the folder tree to a different folder:

1. The folder is placed in the desired folder
2. The desired folder **always** opens after a few msecs.
I have some folders with dozens of sub-folders. Whenever I drag and drop a folder to such folder containing lots of sub-folders, it will always expand regardless how fast I release the mouse button. This only change is the time after it opens.  (Original bug report)

When moving an **object** over the folder tree to a different location **outside** the folder tree, e.g. when you move a message to a explorer windows to save it in the file system. This is what the bug references .

1. The message is saved as expected.
2. The folder in the folder tree that has been passed while moving the object will **always** opens after a few msecs (Comment #6, Comment #15).

From what I see there are at least two bug involved: 1) The folder always opens when an object is dropped regardless of the button release time  and 2) the folder always opens when an object passes this folder without dropping it.

@webmaster2 I'm not sure I've covered all the cases. Maybe you can record the screen to show the problem on your system?
I can confirm the problem (Windows 10, 64bit).

Maybe the description is not sufficient to reproduce the bug. so I'll try to give a more detailed analysis here.

In Windows Explorer the user experience for Drag & Drop is as follows:
--
1. Select a object with the mouse and hold the mouse button pressed.
2. Move the object over the desired folder in the folder tree.

Now following can happen:

**You release the mouse button "< X msec".**

3. The object is placed in the folder without opening it.

**You keep the mouse button pressed "> X msec":**

3. The folder will be opened.
4. You can move the mouse over the sub-folder and release the mouse button to place the object there.

In Thunderbird the user experience is:
--

When moving a **message** to a folder:

Thunderbird behaves like expected in *most* cases. But I have noticed that *sometimes* there is no response. Even if the mouse pointer is held over the folder for a long time, it does not open. If I delete the sub-folder and create it again, the parent folder opens. -> Maybe a different bug, I could not find a way to reproduce it reliable.

When moving a **folder** in the folder tree to a different folder:

1. The folder is placed in the desired folder
2. The desired folder **always** opens after a few msecs.
I have some folders with dozens of sub-folders. Whenever I drag and drop a folder to such folder containing lots of sub-folders, it will always expand regardless how fast I release the mouse button. This only change is the time after it opens.  (Original bug report)

When moving an **object** (message or folder) over the folder tree to a different location **outside** the folder tree, e.g. when you move a message to a explorer windows to save it in the file system. This is what the bug references .

1. The message is saved as expected.
2. The folder in the folder tree that has been passed while moving the object will **always** opens after a few msecs (Comment #6, Comment #15).

From what I see there are at least two bug involved: 1) The folder always opens when an object is dropped regardless of the button release time  and 2) the folder always opens when an object passes this folder without dropping it.

@webmaster2 I'm not sure I've covered all the cases. Maybe you can record the screen to show the problem on your system?
I can confirm the problem (Windows 10, 64bit).

Maybe the description is not sufficient to reproduce the bug. so I'll try to give a more detailed analysis here.

In Windows Explorer the user experience for Drag & Drop is as follows:
--
1. Select a object with the mouse and hold the mouse button pressed.
2. Move the object over the desired folder in the folder tree.

Now following can happen:

**You release the mouse button "< X msec".**

3. The object is placed in the folder without opening it.

**You keep the mouse button pressed "> X msec":**

3. The folder will be opened.
4. You can move the mouse over the sub-folder and release the mouse button to place the object there.

In Thunderbird the user experience is:
--

When moving a **message** to a folder:

Thunderbird behaves like expected in *most* cases. But I have noticed that *sometimes* there is no response. Even if the mouse pointer is held over the folder for a long time, it does not open. If I delete the sub-folder and create it again, the parent folder opens. -> Maybe a different bug, I could not find a way to reproduce it reliable.

When moving a **folder** in the folder tree to a different folder:

1. The folder is placed in the desired folder
2. The desired folder **always** opens after a few msecs.
I have some folders with dozens of sub-folders. Whenever I drag and drop a folder to such folder containing lots of sub-folders, it will always expand regardless how fast I release the mouse button. This only change is the time after it opens.  (Original bug report)

When moving an **object** (message or folder) over the folder tree to a different location **outside** the folder tree, e.g. when you move a message to a explorer windows to save it in the file system. This is what the bug references .

1. The message is saved as expected.
2. The folder in the folder tree that has been passed while moving the object will **always** opens after a few msecs (Comment #6, Comment #15).

From what I see there are at least two bug involved: 1) The folder always opens when an object is dropped regardless of the button release time  and 2) the folder always opens when an object passes this folder without dropping it.
I doubt that is it related to the "hover on folder delay" only.

@webmaster2 I'm not sure I've covered all the cases. Maybe you can record the screen to show the problem on your system?
I can confirm the problem (Windows 10, 64bit).

Maybe the description is not sufficient to reproduce the bug. so I'll try to give a more detailed analysis here.

In Windows Explorer the user experience for Drag & Drop is as follows:
--
1. Select a object with the mouse and hold the mouse button pressed.
2. Move the object over the desired folder in the folder tree.

Now following can happen:

**You release the mouse button "< X msec".**

3. The object is placed in the folder without opening it.

**You keep the mouse button pressed "> X msec":**

3. The folder will be opened.
4. You can move the mouse over the sub-folder and release the mouse button to place the object there.

In Thunderbird the user experience is:
--

When moving a **message** to a folder:

Thunderbird behaves like expected in *most* cases. But I have noticed that *sometimes* there is no response. Even if the mouse pointer is held over the folder for a long time, it does not open. If I delete the sub-folder and create it again, the parent folder opens. -> Maybe a different bug, I could not find a way to reproduce it reliable.

When moving a **folder** in the folder tree to a different folder:

1. The folder is placed in the desired folder
2. The desired folder **always** opens after a few msecs.
I have some folders with dozens of sub-folders. Whenever I drag and drop a folder to such folder containing lots of sub-folders, it will always expand regardless how fast I release the mouse button. This only change is the time after it opens.  (Original bug report)

When moving an **object** (message or folder) over the folder tree to a different location **outside** the folder tree, e.g. when you move a message to a explorer windows to save it in the file system. This is what the bug references .

1. The message is saved as expected.
2. The folder in the folder tree that has been passed while moving the object will **always** opens after a few msecs (Comment #6, Comment #15).

From what I see there are at least two bugs involved: 1) The folder always opens when an object is dropped regardless of the button release time  and 2) the folder always opens when an object passes this folder without dropping it.
I doubt that is it related to the "hover on folder delay" only.

@webmaster2 I'm not sure I've covered all the cases. Maybe you can record the screen to show the problem on your system?
I can confirm the problem (Windows 10, 64bit).

Maybe the description is not sufficient to reproduce the bug. so I'll try to give a more detailed analysis here.

In Windows Explorer the user experience for Drag & Drop is as follows:
--
1. Select a object with the mouse and hold the mouse button pressed.
2. Move the object over the desired folder in the folder tree.

Now following can happen:

**You release the mouse button "< X msec".**

3. The object is placed in the folder without opening it.

**You keep the mouse button pressed "> X msec":**

3. The folder will be opened.
4. You can move the mouse over the sub-folder and release the mouse button to place the object there.

In Thunderbird the user experience is:
--

When moving a **message** to a folder:

Thunderbird behaves like expected in *most* cases. But I have noticed that *sometimes* there is no response. Even if the mouse pointer is held over the folder for a long time, it does not open. If I delete the sub-folder and create it again, the parent folder opens. -> Maybe a different bug, I could not find a way to reproduce it reliable (see bug 1840484 comment 3).

When moving a **folder** in the folder tree to a different folder:

1. The folder is placed in the desired folder
2. The desired folder **always** opens after a few msecs.
I have some folders with dozens of sub-folders. Whenever I drag and drop a folder to such folder containing lots of sub-folders, it will always expand regardless how fast I release the mouse button. This only change is the time after it opens.  (Original bug report)

When moving an **object** (message or folder) over the folder tree to a different location **outside** the folder tree, e.g. when you move a message to a explorer windows to save it in the file system. This is what the bug references .

1. The message is saved as expected.
2. The folder in the folder tree that has been passed while moving the object will **always** opens after a few msecs (Comment #6, Comment #15).

From what I see there are at least two bugs involved: 1) The folder always opens when an object is dropped regardless of the button release time  and 2) the folder always opens when an object passes this folder without dropping it.
I doubt that is it related to the "hover on folder delay" only.

@webmaster2 I'm not sure I've covered all the cases. Maybe you can record the screen to show the problem on your system?
I can confirm the problem (Windows 10, 64bit).

Maybe the description is not sufficient to reproduce the bug. so I'll try to give a more detailed analysis here.

In Windows Explorer the user experience for Drag & Drop is as follows:
--
1. Select a object with the mouse and hold the mouse button pressed.
2. Move the object over the desired folder in the folder tree.

Now following can happen:

**You release the mouse button "< X msec".**

3. The object is placed in the folder without opening it.

**You keep the mouse button pressed "> X msec":**

3. The folder will be opened.
4. You can move the mouse over the sub-folder and release the mouse button to place the object there.

In Thunderbird the user experience is:
--

When moving a **message** to a folder:

Thunderbird behaves like expected in *most* cases. But I have noticed that *sometimes* there is no response. Even if the mouse pointer is held over the folder for a long time, it does not open. If I delete the sub-folder and create it again, the parent folder opens. -> Maybe a different bug, I could not find a way to reproduce it reliable (see bug 1840484 comment 3).

When moving a **folder** in the folder tree to a different folder:

1. The folder is placed in the desired folder
2. The desired folder **always** opens after a few msecs.
I have some folders with dozens of sub-folders. Whenever I drag and drop a folder to such folder containing lots of sub-folders, it will always expand regardless how fast I release the mouse button. This only change is the time after it opens.  (see original bug report comment 0)

When moving an **object** (message or folder) over the folder tree to a different location **outside** the folder tree, e.g. when you move a message to a explorer windows to save it in the file system. This is what the bug references .

1. The message is saved as expected.
2. The folder in the folder tree that has been passed while moving the object will **always** opens after a few msecs (see Comment 6, Comment 15).

From what I see there are at least two bugs involved: 1) The folder always opens when an object is dropped regardless of the button release time  and 2) the folder always opens when an object passes this folder without dropping it.
I doubt that is it related to the "hover on folder delay" only.

@webmaster2 I'm not sure I've covered all the cases. Maybe you can record the screen to show the problem on your system?

Back to Bug 1863845 Comment 27