1826831 - Column picker is wider than needed with floating scrollbars (`select columns to display` column)

Status: RESOLVED WONTFIX

(Thunderbird :: Folder and Message Lists, defect)

Description

[Wayne Mery (:wsmwk)]

Attachment: Screenshot 2023-04-06 at 1.51.33 PM.png

In version 102 the column selector is a fixed width.

On Mac 112 and daily, select columns to display is wider than needed, if the combined width of other columns doesn't force the column selector to it's smallest possible width. I don't see this on Windows.

Comment 1

[Richard Marti (:Paenglab)]

This is intended when you use floating scrollbars because the scrollbar is shown over the column picker. See bug 1820262.

Comment 2

[Thomas D. (:thomas8)]

(In reply to Richard Marti (:Paenglab) from comment #1)

This is intended when you use floating scrollbars because the scrollbar is shown over the column picker. See bug 1820262.

Yes, but the problem is that the implementation allows the scrollbar to take the full height of the entire tree list container, which is why it competes with the column picker in the first place (Bug 1820262 Comment 0). 102 seems to get this right (Bug 1820262 Comment 2): scroll bar ends below the column picker. Per aleca's Bug 1820262 Comment 3, I'm not sure if there's an interest to restore the 102 design (although he might just be saying that it won't be restored in that particular bug).

Wayne, what should we do with this bug then?

Comment 3

[Wayne Mery (:wsmwk)]

Wayne, what should we do with this bug then?

This is not a hill I'm prepared to die on in disagreement.

However, problem is broader in the compose window, if they are the same. If you have a table or image that takes the width or height of the window, then the grab points of the content object (corners for example) are near impossible catch to be able to resize them because the scroll bars interfere (or whatever you want to call it). It's a serious problem. Try it. Does the same thing happen on WIndows?

So I do think it should be changed to work more cleanly, even if the implimentation is more involved.

Comment 4

[Wayne Mery (:wsmwk)]

Attachment: Compose window containing image

In this screen shot you can see the tiny grab squares at the image border, bottom right and on the right just above the blue bar ... both of them stuck under the compose window scroll bar.

Comment 5

[Thomas D. (:thomas8)]

Attachment: Screenshot: Composition with large image and scrollbars on Win10

(In reply to Wayne Mery (:wsmwk) from comment #3)

Wayne, what should we do with this bug then?
This is not a hill I'm prepared to die on in disagreement.
However, problem is broader in the compose window, if they are the same. If you have a table or image that takes the width or height of the window, then the grab points of the content object (corners for example) are near impossible catch to be able to resize them because the scroll bars interfere (or whatever you want to call it). It's a serious problem. Try it.

Agreed, that's a nasty bug. But it's kind of the reverse bug - here we are not happy with the workaround (wider column picker) which was applied to fix the same problem that we are still seeing in composition. So the composition problem should go into a new bug.

Does the same thing happen on WIndows?

Not on Windows 10 (see screenshot).

So I do think it should be changed to work more cleanly, even if the implementation is more involved.

The composition bug, yes. Maybe also in message and folder list. It's a bit weird that scrollbar should be next to elements which don't even move. So far, I only know that scroll bars should be next to scrollable elements, not fixed elements.

Comment 6

[Alessandro Castellani [:aleca]]

We're keeping this implementation for now since the table header of the message list is in a sticky position.
The problems with the composer and scrollbars is completely unrelated.