Michał Reporter
	Description • 13 years ago

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Build ID: 20110928134238

Steps to reproduce:

as described in bug 551363, 511362, 549684, 522751.


Actual results:

The reason I've decided to post this bug is that the behaviour is consistent across the whole TABs system.
You treat folders very simillar to messages if displayed in tabs.


Expected results:

I think that the reasonable behavior is as follows:
1. For folders and tabs:
-a- if clicked on folder in the first tab on the left – main tab - change the view to that folder with the focus on the same tab,
-b- if double-clicked on folder check if there is an already assigned tab(s) and open the most recently displayed one or create a new tab with the folder and focus on it,
-c- if clicked right and chosen "open" then same as point -b-,
-d- if clicked right and chosen "open in new tab" open a new tab and focus on it.
2. For messages and tabs:
-a- if double-clicked on a message check if there is an already assigned tab(s) and open the most recently displayed one or create a new tab with the message and focus on it,
-b- if clicked right and chosen "open message in new window" open it in a new window,
-c- if clicked right and chosen "open message in new tab" open it in a new tab,
-d- if clicked once display it in a preview window if it exists.
I think this saves a lot of worries for everybody frustrated with repeated tab contents while giving the freedom to use as many tabs for a single folder/message as one wishes.
It would also be most welcome if the messages/folders displayed currently in tabs were marked with a different color on the list of messages/folders.

One last remark - you managed to master switching from one tab to another using a list of tabs on the right side in Firefox 7.0.1. If one clicks on "invisible" in the current view tab the tabs scroll to the required tab so the focus and display are in accordance. You were not able to do it in Thunderbird/Earlybird 7.0. It may be worth borrowing some code from Firefox team.

	Michał Reporter
	Comment 1 • 13 years ago

The bug 577655 is also relevant to the above.

	Ludovic Hirlimann [:Usul]
	Comment 2 • 13 years ago

(In reply to Michał from comment #1)
> The bug 577655 is also relevant to the above.

Do you think it's the same bug ?

	Michał Reporter
	Comment 3 • 13 years ago

Yes, it is in my opinion because it points to the same inconsistencies in message tabs system.

	Thomas D. (:thomas8)
	Comment 4 • 13 years ago

(In reply to Ludovic Hirlimann [:Usul] from comment #2)
> (In reply to Michał from comment #1)
> > The bug 577655 is also relevant to the above.
> Do you think it's the same bug ?
(In reply to Michał from comment #3)
> Yes, it is in my opinion because it points to the same inconsistencies in
> message tabs system.

Well, certainly this bug and bug 577655 are similar in that they are about problems or enhancements of the message tabs system. Furthermore, this bug (avoidable duplication of existing tabs) can lead into experiencing problem of bug 577655 (with many tabs, active tab top sometimes hidden).

Notwithstanding, this bug and bug 577655 are fundamentally different, if only because this bug is an request for enhancement (RFE), while bug 577655 is clearly a bug (and annoying, too). Hence there is no way we could merge this bug with bug 577655, as proposed in comment 1, comment 3, and bug 577655, comment 14. But Michał is right that there are some inner connections which we should keep in mind, and track as appropriate (in comments, "see-also" field, or with dependencies).

(In reply to Michał from comment #0)
> Steps to reproduce:
> as described in bug 551363, 511362, 549684, 522751.

Michał, this won't work. There are several problems with your "steps to reproduce" (STR):

* to begin with, please use correct syntax for linking multiple bugs (as you can see in your comment 0, only bug 551363 was linked): bug 551363, bug 511363, bug 549684, and bug 522751. Unfortunately, there is no other syntax that will link multiple bugs, and yes, we already have bugs filed against bugzilla for that annyoing problem of inefficiency. But things take time. If your bug references are not linked, you are making it unnecessarily hard for other people to retrieve the information you want them to see.

* We have a policy of "one issue per bug", and for the rare occasions where this policy doesn't apply, the people who correctly ignore it will know that there are good reasons and that they are entitled to do so. If you are not sure, pls limit yourself to one small specific issue per bug. Doing so will increase the chances of "your" bug/rfe being understood and receiving attention.

* the biggest problem is that you cannot expect your readers to dig into as many as four different bugs and reconstruct what you want them to see as "your STR" for this bug. Really, you have to write out the STR for each bug in the bug itself, in full. Otherwise, no chance that anybody will ever even look at your problem.

* Finally, while your comprehensive proposal for a consistent behaviour in comment 0 is good, you need to indicate which aspects are current behaviour and where you are proposing changes to the current behaviour. So in fact, it's better to list those aspects that change separately, to reduce the analytical burden of understanding your proposal. Then, in addition, you may provide the full overview of behaviour with current and new aspects clearly indicated.
 
> Actual results:
>
> The reason I've decided to post this bug is that the behaviour is consistent
> across the whole TABs system.
> You treat folders very simillar to messages if displayed in tabs.

This is not an adequate description of the actual behaviour that you are trying to improve.

> Expected results:
> 
> I think that the reasonable behavior is as follows:
> 1. For folders and tabs:
> -a- if clicked on folder in the first tab on the left – main tab - change
> the view to that folder with the focus on the same tab,

yes, we do that already (current behaviour)

> -b- if double-clicked on folder check if there is an already assigned tab(s)
> and open the most recently displayed one or create a new tab with the folder
> and focus on it,

that's a valid RFE: double-clicking a folder should default to opening the folder in a new tab
If there is no bug for that yet, I'd recommend filing a new one (as we can't morph this one), with all the necessary details for STR, Actual behaviour, and Expected behaviour. It's similar, but not identical with Bug 511362.

> -c- if clicked right and chosen "open" then same as point -b-,

that's unlikely, because in the current design right-clicking on a folder will not open that folder for viewing in current tab, so "Open" is currently used to do that.

> -d- if clicked right and chosen "open in new tab" open a new tab and focus
> on it.

we do that already (current behaviour)

> 2. For messages and tabs:
> -a- if double-clicked on a message check if there is an already assigned
> tab(s) and open the most recently displayed one or create a new tab with the
> message and focus on it,

that's a good idea, as a duplicate of bug 551363, which seems to be the core of this bug.

> -b- if clicked right and chosen "open message in new window" open it in a
> new window,

current behaviour 

> -c- if clicked right and chosen "open message in new tab" open it in a new
> tab,

current behaviour

> -d- if clicked once display it in a preview window if it exists.

that's single-left click on msg in msg list to trigger msg preview in msg reader preview pane:
same as current behaviour

> I think this saves a lot of worries for everybody frustrated with repeated
> tab contents while giving the freedom to use as many tabs for a single
> folder/message as one wishes.
> It would also be most welcome if the messages/folders displayed currently in
> tabs were marked with a different color on the list of messages/folders.

Very true. That's my Bug 692062, which got duplicated into Bug 686959. I have just enquired about the progress of that bug.

> One last remark - you managed to master switching from one tab to another
> using a list of tabs on the right side in Firefox 7.0.1. If one clicks on
> "invisible" in the current view tab the tabs scroll to the required tab so
> the focus and display are in accordance. You were not able to do it in
> Thunderbird/Earlybird 7.0. It may be worth borrowing some code from Firefox
> team.

I'd think the problem is that we can't copy *all* the code from firefox, and things can break easily while we adjust some portions of FF code to blend in with our existing code. It all boils down to a question of manpower, which unfortunately is very limited for TB.

So in conclusion, most aspects requested by this bug are already current behaviour, and those which are not are either duplicates of other bugs, or they require new bugs with one issue per bug.