545906 - Make column pickers sticky/persistent (menu should behave like a panel, i.e. stay open for selecting multiple columns until user clicks outside or ESC)

Status: RESOLVED FIXED

(Thunderbird :: Folder and Message Lists, enhancement)

Description

[Charles]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6
Build Identifier: 3.0.1 final

Minor but annoying thing (especially since I seem to have to change these a lot because they mysteriously revert at random times)...

I'd like to see the message pane view column picker (and the rest of the column pickers) be sticky/persistent - meaning, when you click it, the list of columns drops down and stays down allowing you to click on different labels enabling/disabling items in the list until you get it the way you want. Then juct click off of the displayed list of columns to close it.

Reproducible: Always

Steps to Reproduce:
1. Click the column picker
2. Click on a column label to enable/disable it
3. Column picker closes immediately
Actual Results:  
ditto

Expected Results:  
1. Click the column picker
2. Click on a column label to enable/disable it
3. List of columns stays open
4. Continue clicking on different column labels to enable/disable them until I've selected/deselected all of the ones I want to
5. Click off of the column picker drop down window (or back on the column picker 'button') to make the column picker close

Comment 1

[Thomas D. (:thomas8)]

Thank you, Charles. Definitely right, we have no reason to assume user wants to change a single column only, and this bug makes (un)selecting of multiple columns unnecessarily hard. Column picker should be implemented as a panel (if it isn't yet) and behave like a panel, i.e. stay open until user clicks outside (which includes the column picker button) or presses ESC.

I think this is a toolkit issue, but then, do toolkit bugs ever get fixed if we change product to toolkit?

Comment 2

[Wayne Mery (:wsmwk)]

(In reply to comment #1)
> I think this is a toolkit issue, but then, do toolkit bugs ever get fixed if we
> change product to toolkit?

they do if you supply the patch! ;-)

Comment 3

[alta88]

Attachment: colpicker.patch

yes, this is really annoying.

Comment 4

[alta88]

i suppose this can be done generically in toolkit, meaning the autogenerated picker menupopup's menuitem attribute is derived from the column's attribute.

Comment 5

[alta88]

Comment on attachment 9081429 [details] [diff] [review]
colpicker.patch

Let's see what happens in Bug 1569791.

Comment 6

[alta88]

Attachment: closemenuTb.patch

This makes the column picker menus sticky for folderpane, threadpane, and advanced search list. Requires the patch in Bug 1569791.

Comment 7

[Alessandro Castellani [:aleca]]

Comment on attachment 9081661 [details] [diff] [review]
closemenuTb.patch

Review of attachment 9081661 [details] [diff] [review]:
-----------------------------------------------------------------

Indeed this was really annoying, thanks for taking care of it.
r+

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/055cf553a73e
Make threadpane and folderpane column picker popups stay open for multiple selects. r=aleca

Comment 9

[Charles]

Any chance this can be uplifted so it makes it into the upcoming ESR?

Comment 10

[alta88]

the sheriff would have to decide if the required special uplift of the required m-c patch is worth it. imo, it would be nice.

Comment 11

[Jorg K (CEST = GMT+2)]

Please request uplift here and quote the m-c bug. Oh, it's in comment #6.

Comment 12

[alta88]

Comment on attachment 9081661 [details] [diff] [review]
closemenuTb.patch

no risk. also requires m-c changeset https://hg.mozilla.org/mozilla-central/rev/8d408d3d062c

Comment 13

[Jorg K (CEST = GMT+2)]

"No risk" is funny ;-) - How many endless hours have I discussed about "no risk" or "low risk" patches :-(

Since so far we don't have a TB release branch on M-B, this would have to go straight to ESR 68 where we do have such a branch. I'll see what I can do. At the very latest, we can ship it in TB 68.2 after spending time in TB 70 beta which is released with TB 68.1.

Comment 14

[alta88]

I don't rightly know, were you ever a professional statistician? ;) Do we have loss functions for patches? Or thresholds for "low"? I'll go out on a limb and say there is 0 risk (rather than the fuzzy so low it approaches no that I meant). And as you know, 0 risk (Bayes, integrated) is theoretically legitimate. Oh, and I do exclude operational mistakes like copy/paste errors whilst transplanting, etc etc.

Slow day ;)

Comment 15

[Jorg K (CEST = GMT+2)]

Comment on attachment 9081661 [details] [diff] [review]
closemenuTb.patch

This is nice, I looked at it in Daily. Patch is low-risk, so I think it's a good idea to ship this with TB 68.0 ESR as a new "feature" and not slip it into a dot release later. Besides, no one will be upgraded to 68.0, upgrades will start from 68.1. I'll take care of the M-C uplift required.

Comment 16

[Jorg K (CEST = GMT+2)]

TB 68.0 ESR:
https://hg.mozilla.org/releases/comm-esr68/rev/ba8630fdfa1b26235bda8447386d7d787225d8b7

Comment 17

[Jorg K (CEST = GMT+2)]

The side effect is that add-ons adding a column now need to add the closemenu="none" otherwise picking their column still closes the menu.

Comment 18

[alta88]

Correct. It's not unreasonable to document that addons should do that, but it might be better to ensure it when custom columns are registered. Or maybe do in the custom element code like the original patch did. Many of the worst problems with custcol were fixed a while ago, and the biggest one remaining is that they aren't handled in View->Sort by at all unless the addon goes out of its way to do it.
Thanks for the uplifts.