Closed Bug 35389 Opened 25 years ago Closed 3 years ago

Double click folder and original folder also switches


(SeaMonkey :: MailNews: Message Display, enhancement)

Not set


(Not tracked)



(Reporter: nbaca, Unassigned)



Build 2000-04-10-08M15: NT4, Linux 6.0, Mac 8.5.1

Overview: Double click onto a folder and the original folder also changes.

Steps to reproduce:
1. Select the Inbox 
2. Double click onto a newsgroup

Actual Results: A new 3-pane window appears but notice that the 1st and 
2nd window displays the contents of the newsgroup.

Expected Results: The 1st window should display the Inbox contents and the 2nd 
window should display the newsgroup contents.
QA Contact: lchiang → nbaca
Target Milestone: --- → M17
moving to future milestone.
Target Milestone: M17 → Future
This also happens when trying to open a new window via right click, which also
shouldn't change folders in the original window.
*** Bug 58009 has been marked as a duplicate of this bug. ***
Nominating for nsdogfood.
Keywords: nsdogfood
converting nomination from dogfood to catfood, the workaround is to click on the
inbox in one of the windows...
Keywords: nsdogfoodnsCatFood
Keywords: nsCatFoodnsCatFood+
Clearing future to get re-evaluation for MachV.  Workaround is still very
disruptive, due to losing selection and scroll state in the inbox (bug 48120),
and requiring extra clicks to get the folders you wanted open and the new one
active. Of course, some people may not even notice that the inactive window is a
duplicate until they try to switch back to their inbox and find it isn't open. 
This may not affect a large number of users, but IMO the ability to have
multiple folders open is of little or no value while this defect exists.
Target Milestone: Future → ---
*** Bug 95444 has been marked as a duplicate of this bug. ***
reassigning to ssu
Assignee: putterman → ssu
Keywords: nsbeta1
Keywords: nsbeta1nsbeta1+
Target Milestone: --- → mozilla0.9.9
QA Contact: nbaca → olgam
*** Bug 109544 has been marked as a duplicate of this bug. ***
Blocks: 122274
Keywords: nsbeta1+nsbeta1-
Target Milestone: mozilla0.9.9 → mozilla1.2
This bug is bothering folks.  I have email from one user who says he uses mozilla 
for composer but not for mail becasue of this bug.  This bug also irks me as 
well, since I try to use NS for multiple mail accounts.  Any way we can reel this 
one in?
Hopefully the fixing of bug 30560 will reduce the severity of this problem.
I must confess ignorance of how a 30560 fix would help.  30560 is about right 
clicking.  This is about double clicking.  ??  
I'm sorry if I have confused you. I did not realize that 4.x doesn't handle
right-clicks in the same way that Outlook Express does, and hopefully Mozilla
(assuming bug 30560 is fixed) will. This will provide a means of opening a
different folder in a new window, although in the way 4.x did.
I was trying to fix this problem while working on bug 30560.  Bug 30560 will
allow the user to open a new folder in a new mailnews window (without switching
the folder in the original mailnews window) via the right mouse click menu.  It
does not fix it via a double click.

The problem with a double click is that the switching/selecting to the newly
clicked folder is done on a 'mousedown' event, regardless if it's a double click
or not.  Then the double click event is caught and a new mailnews window is
created for the newly selected folder.

A way to fix this is to not perform the 'selection' call on the mousedown event,
but on a mouseup event after it's been determined if the user performed a double
or a single click (of the left mouse button).

I'm still investigating the different ways of fixing the bug.
This bug occurs on Linux and Mac OS X in addition to Windows, thus should not be
limited to just the Windows platform in its categorization. Please adjust OP_Sys
from WinNT to All. Ditto platform.

And yes, it is a tremendously annoying bug. The following cases should not cause
selection to swtich to the clicked folder:

1. Double-clicking the folder to open in a new (#2) window should not cause the
folder selection to change in the original (#1) window.

2. Dragging a folder to move it under another folder for organization purposes
should not change the selection to that folder. For example, if you have a
Folder called "Apples" and other called "Oranges" and the active folder is
"Inbox" you should be able to click apples and drag it to appear under Oranges
without changing the active from Inbox.

3. Right-clicking a folder should not change the selection. 
OS: Windows NT → All
Hardware: PC → All
In comment 14, Sean said:

"A way to fix this is to not perform the 'selection' call on the mousedown event,
but on a mouseup event after it's been determined if the user performed a double
or a single click (of the left mouse button)."

One note is that there is existing logic in the mail/news window today where you
click on a folder, then use the arrow keys to go up/down through the list. Even
though you are moving through the list, the mail client doesn't actually change
the selection of the active folder until you stop keying up/down through the
list and settle on a particular folder.

Thus, perhaps the same timer logic that drives that use case could be used here
to measure the time after the mouseup.
I remove nsbeta1- keyword - it was for MachV.
Keywords: nsbeta1-
Now I add 'nsbeta1' keyword for Buffy. Sorry, it's faster to edit multiple bugs
at once than manually go to each and remove minus.
Keywords: nsbeta1
Assignee: ssu → sspitzer
Keywords: nsbeta1nsbeta1-
QA Contact: olgam → laurel
*** Bug 94880 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
Assignee: sspitzer → mail
Over 5 years since it has been reported, and this bug still exists today
(Thunderbird 1.0 on WinXP).  Is it really that hard to fix?
I think the behavior requested by this bug is bad UI -- double-click is 
supposed to move the selection.  If moving the selection isn't desired, that's what right-click is for; and right-click, Open is implemented for just this situation.

See also bug 214114, which implements a pref to change the folder double-click 
behavior from Open to Expand/Collapse, just as it's been when double-clicking 
an account node.
*** Bug 202591 has been marked as a duplicate of this bug. ***
Agree with Mike, requested behavior seems at odds with other examples of double click. comment 2 is no longer true.

WONTFIX?  Or leave it open forever?
Severity: normal → enhancement
QA Contact: laurel
I guess I don't understand - where else is it OK to change the contents of the original selection with a double click?  The whole point of a double-click is to differentiate it from a single click.  Since the behavior of the single click is to change focus and a double click is to open a new window, WHY would you want to change focus as part of an operation designed to open a new window?  I can't think of many UI examples where you intentionally create a redundant identical element (after all, you are essentially changing one window with a unique focus and creating a second but redundant focus for both in a new area).  If you think about it, most common usage when you open a new window is to show different content from the original - if so, why is it intended that you rarely follow typical usage?  This is VERY non-intuitive. 
Priority: P3 → --
QA Contact: search
Target Milestone: mozilla1.2alpha → ---
Assignee: mail → nobody
QA Contact: search → message-display
The only issue I see with the behaviour here is that the original window is displaying the wrong title (i.e. Inbox) instead of the name of the newsgroup.
There are three options:
* Disable double click on folders (as TB now does);
* Fix issue with original window title;
* Do something else with the double click behaviour;
Flags: blocking1.9.0.19?
Flags: blocking1.9.0.19?

mailnews.reuse_thread_window2 defaults to true, so you have to set it to false to see the double click behaviour.
As middleclick on a folder opens a new mail tab with that folder leaving the original tab with the previous folder selection, I propose this is closed as WONTFIX

Flags: needinfo?(frgrahl)

I propose this is closed as WONTFIX

Sounds like a plan. There are a ton of tab configuration options already available and I think we won't want to add a new one just for this.

Closed: 3 years ago
Flags: needinfo?(frgrahl)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.