522751 - Folder opened in its own tab loses focus when another folder is selected

Status: RESOLVED INVALID

(Thunderbird :: Toolbars and Tabs, enhancement)

Description

[Lenny]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.19) Gecko/20081216 Fedora/2.0.0.19-1.fc8 Firefox/2.0.0.19
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.5pre) Gecko/20091016 Shredder/3.0pre

In your default view - inbox for most with folder list to left, right click on a folder, like sent - and select open in tab. The Sent mail folder is opened in a tab. Great. Select the tab to display msgs in sent folder, ok. Now select another folder - left click on folder - local folder, inbox - the tab now displays the new folder - Sent is no longer in the tab. With the tab selected, it changes to any new folder you select. It should only occur in the default view. Other tabs should not change when new folders are selected.

Reproducible: Always

Steps to Reproduce:
1.Right click on sent folder - open in tab
2.Select the tab to display contents
3.select a new folder - like trash or inbox
4. The new folder selected is now in the tab
Actual Results:  
The new folder selected is now in the tab

Expected Results:  
Folders selected to be opened in a tab - should remain in the tab. Changing to a new folder should not change the tab folder.

Testing the nightly build on Fedora 8

Comment 1

[Ludovic Hirlimann [:Usul]]

So what you are saying is that the first tab should be a special tab - where selection of a new folder does change the list but when a folder get's opened in a tab then that tab gets a special attribute to make sure that other selection do not break the current one. Right ?

Comment 2

[Lenny]

Yes, That is correct. I think there is some intent to the effort of opening a folder in a tag. The functionality of changing the contents to reflect the selected folder shows the current focus selected. I think the effort of specifically opening a folder in a tab shows they want to access that folder later in the session, so changing the contents prevents the tab access.

Comment 3

[Dave Trollope]

I just opened Bug 549684 which is related to this - but has a narrower scope, to auto switch tabs when a folder is already open in a tab.

Its simpler than having a special tab, but won't cover the case when you select a third folder as this bug would.

Comment 4

[Thomas D. (:thomas8)]

If I understand this bug correctly, then I think it's invalid, or incomplete, or wontfix.

Let me rephrase what I understand here, and please correct me where I'm wrong:

STR
1) from home tab (3pane), right-click on a folder (e.g. Sent) in folder pane, then "open in  new tab"
2) focus the new tab which shows the folder (Sent)
3) from folder pane of "new tab" (Sent), single-left-click on another folder (Trash)

Actual result
after 3), "new tab" will now show Trash folder instead of Sent folder

Expected result (per comment 0)

single-left-click on another folder from "new tab"'s folder list should do - what?
- be ignored? that's invalid, or wontfix, because it violates basic UI expectations and I can't imagine a good way of showing that this is now a static folder tab for a single folder only and any other folders in that tab are forbidden ground
- open the folder in a new tab? that's certainly wontfix, because it's completely unexpected, we have no way of showing that this is now a static folder tab reserved for that folder only. we would also create behaviour inconsistencies between the behaviour in main 3pane home tab and other 3pane tabs. Apart from the position, there's no way to tell apart home tab's 3pane from any other 3pane.

And I don't see the problem: If you don't want to show another folder in that tab, then don't pick another folder in that tab. Go back to home tab, or, from "new tab", use right-click on another folder > "open in a new tab" again.

Perhaps something to consider is if generally, we could have double-click on folder behave differently from single click (single-click: show folder in this tab; double-click: open folder in new tab), similar to how we behave for msgs. But that would need a new bug, not this one.

So if above is correct, I'd close this bug either invalid, incomplete, or wontfix.

Lenny (reporter), can you comment?
Dynamis (who confirmed this bug between comment 2 and comment 3), can you state why you confirmed this? And in which way is this a bug, and not a feature enhancement?

Comment 5

[Thomas D. (:thomas8)]

Furthermore, relationship to Bug 511362 and Bug 549684 should be examined.

Comment 6

[W_Moerner]

I see this bug another way.  Suppose I start in a perfectly standard way with two tabs open, Inbox and Sent, and I have Inbox as the current focus (i.e, the tab that is highlighted, active).  I have a particular email highlighted in the right window, because I want to move this email to a new folder, i.e., out of the Inbox folder.

In the Folder pane, I want to find the target folder, which is several levels down in the folder tree.  If I am VERY careful and click on the + sign to the left of a folder, I can see its subfolders.  BUT, if I click out to the LEFT of the plus sign, then pow, my focus changes AWAY from Inbox!!  

Basically, if you miss the tiny plus sign by mistake, the folder in the Tab switches when we do not want it to do so.  

This problem occurs every time on Win XP or Win 7 Tbird 11.0.1 and all previous versions of Tbird.  (But it did NOT occur if the Penelope extension was installed to mimic Eudora) 

Two suggestions:  
(a) Require double-click to change focus, while single click only navigates in the folder pane.  This would mimic the old Eudora behavior.
(b) Don't change focus if the user clicks out to the LEFT in the Folder pane, but DO change focus if the user clicks on the right, i.e. on the folder name itself.  

Some improvement in this would REALLY HELP in being able to navigate around the folder pane without having a lot of unintended behaviors.  It would help a lot when trying to put emails away in the correct folders quickly. 

Thanks!

Comment 7

[Thomas D. (:thomas8)]

W_Moerner, thx for contributing!

(In reply to W_Moerner from comment #6)
> I see this bug another way.  Suppose I start in a perfectly standard way
> BUT, if I click out
> to the LEFT of the plus sign, then pow, my focus changes AWAY from Inbox!!  
> Basically, if you miss the tiny plus sign by mistake, the folder in the Tab
> switches when we do not want it to do so.  

Agreed, that's a bit odd and could be improved: That's bug 128369, currently filed against SM.

> Two suggestions:  
> (a) Require double-click to change focus, while single click only navigates
> in the folder pane.  This would mimic the old Eudora behavior.

We can't do that because it would violate ux-consistency with almost anything else out there, including windows explorer.

> (b) Don't change focus if the user clicks out to the LEFT in the Folder
> pane, but DO change focus if the user clicks on the right, i.e. on the
> folder name itself.

Fair enough, but I think we'd get complaints from users who expect clicking *outside* the twisty *should* select and focus the folder. And again, no precedent for such behaviour, so it would not be very discoverable or ux-consistent.

Hence imo bug 128369 is a better solution: Just make the click target of the twisty a bit larger so that it covers a few pixels to the *left* of the actual twisty (as we do for the right side).

> Some improvement in this would REALLY HELP in being able to navigate around
> the folder pane without having a lot of unintended behaviors.  It would help
> a lot when trying to put emails away in the correct folders quickly. 

W_Moerner, maybe there are better ways to do that. How about this:

After selecting messages for moving/copying, right-click on selection, then from context menu, "Move to >", then hover via popup menus to target folder. As long as you don't click, no risks, no accidents, no loss of focus.

Then, if you want to move/copy some more messages from any folder to the same target folder again, use Ctrl+Shift+M on selected msgs which will repeat the last action (move/copy into last-used target folder of a move/copy operation).

Comment 8

[Thomas D. (:thomas8)]

Closing invalid per my comment 4, and no response from reporter.
No proposals here that would not badly break ux-consistency.