35389 - Double click folder and original folder also switches

Status: RESOLVED WONTFIX

(SeaMonkey :: MailNews: Message Display, enhancement)

Description

[Ninoschka Baca]

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.

Comment 1

[scottputterman]

moving to future milestone.

Comment 2

[Akkana Peck]

This also happens when trying to open a new window via right click, which also
shouldn't change folders in the original window.

Comment 3

[laurel]

*** Bug 58009 has been marked as a duplicate of this bug. ***

Comment 4

[Dan Mosedale (:dmosedale, :dmose)]

Nominating for nsdogfood.

Comment 5

[selmer (gone)]

converting nomination from dogfood to catfood, the workaround is to click on the
inbox in one of the windows...

Comment 6

[Peter Trudelle]

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.

Comment 7

[Mike Schuette]

*** Bug 95444 has been marked as a duplicate of this bug. ***

Comment 8

[scottputterman]

reassigning to ssu

Comment 9

[scottputterman]

*** Bug 109544 has been marked as a duplicate of this bug. ***

Comment 10

[Joe Francis]

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?

Comment 11

[[e-mail]]

Hopefully the fixing of bug 30560 will reduce the severity of this problem.

Comment 12

[Joe Francis]

I must confess ignorance of how a 30560 fix would help.  30560 is about right 
clicking.  This is about double clicking.  ??  

Comment 13

[[e-mail]]

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.

Comment 14

[Sean Su]

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.

Comment 15

[Angus Davis]

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. 

Comment 16

[Angus Davis]

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.

Comment 17

[Olga]

I remove nsbeta1- keyword - it was for MachV.

Comment 18

[Olga]

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.

Comment 19

[(not reading, please use [e-mail] instead)]

taking

Comment 20

[Andreas Kunz]

*** Bug 94880 has been marked as a duplicate of this bug. ***

Comment 21

[Julian Hall]

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?

Comment 22

[Mike Cowperthwaite]

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.

Comment 23

[Mike Cowperthwaite]

*** Bug 202591 has been marked as a duplicate of this bug. ***

Comment 24

[Wayne Mery (:wsmwk)]

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?

Comment 25

[Michael Baffoni]

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. 

Comment 26

[Ian Neal]

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;

Comment 27

[Ian Neal]

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

Comment 28

[Frank-Rainer Grahl (:frg)]

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.