Closed Bug 545906 Opened 11 years ago Closed 2 years ago

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)

Categories

(Thunderbird :: Folder and Message Lists, enhancement)

enhancement
Not set
normal

Tracking

(thunderbird_esr6868+ fixed, thunderbird69 wontfix, thunderbird70 fixed)

RESOLVED FIXED
Thunderbird 70.0
Tracking Status
thunderbird_esr68 68+ fixed
thunderbird69 --- wontfix
thunderbird70 --- fixed

People

(Reporter: tanstaafl, Assigned: alta88)

References

Details

Attachments

(1 file, 1 obsolete file)

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
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?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hardware: x86 → All
Summary: Make column pickers sticky/persistent → 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)
(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! ;-)
Attached patch colpicker.patch (obsolete) — Splinter Review

yes, this is really annoying.

Assignee: nobody → alta88
Attachment #9081429 - Flags: review?(alessandro)

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 on attachment 9081429 [details] [diff] [review]
colpicker.patch

Let's see what happens in Bug 1569791.
Attachment #9081429 - Flags: review?(alessandro)

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

Attachment #9081661 - Flags: review?(alessandro)
Depends on: 1569791
Blocks: 297251
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+
Attachment #9081661 - Flags: review?(alessandro) → review+
Keywords: checkin-needed
Attachment #9081429 - Attachment is obsolete: true

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/055cf553a73e
Make threadpane and folderpane column picker popups stay open for multiple selects. r=aleca

Status: NEW → RESOLVED
Closed: 2 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 70.0

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

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.

Flags: needinfo?(jorgk)

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

Flags: needinfo?(jorgk)
Comment on attachment 9081661 [details] [diff] [review]
closemenuTb.patch

no risk. also requires m-c changeset https://hg.mozilla.org/mozilla-central/rev/8d408d3d062c
Attachment #9081661 - Flags: approval-comm-esr68?

"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.

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 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.
Attachment #9081661 - Flags: approval-comm-esr68? → approval-comm-esr68+

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.

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.

You need to log in before you can comment on or make changes to this bug.