Labeling outside of a bundle keeps the conversation selected

[msuozzo]

trafficstars

Maybe this is more an FR than a bug but a common workflow I have is the following:

1. Select conversation not in bundles (key: x)
2. Manually add a label to that conversation (key: L -> up/down -> space -> enter)
3. Goto 1

However the current implementation means that after the first conversation is labeled and moved into a bundle, that conversation remains selected in spite of now being visually hidden within a bundle. This means that when selecting a second conversation and trying to apply a new label, that label is also applied to the first conversation.

Would it be possible to either...

1. Change this behavior when bundles are enabled or..
2. Add a toggle to clear selection when label(s) applied

Thanks for building an amazing tool!

[leggett]

Fantastic catch! I'm not sure how easily I can correctly unselect the message, but maybe. Another option would be to expand the bundle so you can see it is selected but this would collapse any other already-expanded bundles. I'll give it a think...

[msuozzo]

So I actually like the behavior of silently moving the conversation to the bundle since my categorization workflow is sequential through the inbox. Pulling focus to a bundle would be a bit disorienting and require navigating back to my previous location.

[leggett]

I agree. I think unselecting the message in this case, while not consistent when the message doesn't go into a bundle, is the better experience.

[leggett]

Ok, I've got this working now and will include it in the next update. Thanks for the report!

• I unselect a thread when put into a bundle that is collapsed.
• I also unselect anything that is selected when you collapse a bundle.

[msuozzo]

Thanks so much!

Testing the fix, I think I stumbled on a variant of this but when removing from a bundle: When selecting a message inside an expanded bundle and removing that bundle's label, the message disappears from the list but remains selected.

Should I open a new issue for that case or would re-opening this one make sense?

[leggett]

Oof. That's a lot harder to do.

Basically, any time you change anything in the list (add or remove a label, mark something as unread, delete a thread, checks for new mail, etc), Gmail erases and rebuilds the entire list in the code in the blink of an eye.

I have to do a lot to try and maintain continuity across those rebuilds. For putting a message into a label, I can tell (get the threads in a collapsed label that is still selected and unselect it). But for something outside a bundle, there isn't an easy way to distinguish between messages that were in a bundle and just unlabeled and messages that were never in a bundle.

I'll give it some more thought and see if I can think of any way.

[msuozzo]

Interesting. In my case, I was unlabelling a message that had other labels so, I'd assume, it would also be present in a collapsed bundle after the unlabelling action. Not sure how common that is but I have a few filters that overlap slightly and occasionally require manual resolution.

As for the bundle -> non-bundle case, that does seem tricky. I could potentially see that as a tolerable gap given that bundles themselves incentivise keeping the set of non-bundled items relatively small. That would make it marginally less likely for the user to be caught off guard by the retained selection.

[leggett]

That's an interesting case that I think should work. I'll see if I can figure out what is going on.

It is also a lot worse as the selected thread is not visibly selected (granted in the case where it doesn't go into a bundle, it still may be way off screen).