1834656 - Resizing column width is very difficult since version 115. Improve the elastic resizing of the tree view columns.

Status: NEW

(Thunderbird :: Folder and Message Lists, defect, P3)

Description

[Alessandro Castellani [:aleca]]

When resizing the tree view columns a fixed width value is set: https://searchfox.org/comm-central/rev/5391ea879779884999142a67920e99c83ea356bd/mail/base/content/widgets/tree-view.mjs#2083

This works okay as it doesn't allow to resize columns outside the limits of the table layout, but unfortunately it doesn't work as well as 102 used to.

The old XUL tree had a more "elastic" behavior in which a flex value was set on the columns in order to let them grow or shrink based on the size of the viewport or the application.
That allowed a more natural proportional sizing of the columns.

It would be nice to emulate that behavior and improve the experience of our tree view columns.

Comment 1

[Alessandro Castellani [:aleca]]

This is something that we will explore during this cycle to improve the general usability of the tree view, but it something that requires more thinking and prototyping so for now we're going to put it in the backlog.

Comment 7

[Marco Rossi]

It is really surprising that the problem of a dynamic resizing of the area in the classic view is already open after many months...

Comment 9

[Jim Moe]

TB 115.9.0

I have tried to comprehend how the column positioning is supposed to work, without success. Nor do I understand why it has been made so complicated. I adjust one column and other columns resize on their own. Sometimes column positioning tracks the mouse, other times not. Sometimes the changes are saved, other times not; it seems to depend on the selection of en-/disabled columns.

Is there an option somewhere that reverts this function to some mindlessly simple column positioning?

Comment 10

[Wayne Mery (:wsmwk)]

From user POV this behavior is a defect+regression.

Comment 11

[Wayne Mery (:wsmwk)]

Can we prioritize this work for the coming months?

Comment 17

[Alessandro Castellani [:aleca]]

This something that we will address as part of bug 1850893.
It requires a careful rearchitecture of the columns resizing logic and we shouldn't target 128 ESR.
This is something that needs longer beta testing and iterative rollouts.

Comment 18

[Jim Moe]

TB 115.12.0

A further annoyance: After repositioning columns, TB appears to have saved the settings since the columns are where I put them during a previous session (Yay!). Opening TB a second time finds that folder's columns have reverted to the undesired previous setting.
So: position column(s), exit TB, start TB and columns use new settings, exit, start, columns have reverted.

Comment 19

[chrizilla]

Attachment: resizing columns in TB 115.6.1.gif

(In reply to Alessandro Castellani [:aleca] from comment #0)

it doesn't work as well as 102 used to.

Why not keep the behaviour of TB 115.6.1 (see animation)? What's bad about this?

Comment 20

[Alessandro Castellani [:aleca]]

(In reply to chrizilla from comment #19)

Why not keep the behaviour of TB 115.6.1 (see animation)? What's bad about this?

It currently works exactly as your GIF, we didn't change the behavior during this ESR cycle.
The problems start appearing if users resize the last column, which forces a fixed width and it doesn't shrink normally.

I guess we could mitigate the issue by enforcing an "ignore inline width if it's the last column" sort of temporary workaround.

Comment 21

[chrizilla]

(In reply to Alessandro Castellani [:aleca])

comment #1: requires more thinking and prototyping
comment #17: It requires a careful rearchitecture of the columns resizing logic

Why reinvent the wheel ("rearchitecture", "new column resizing logic") instead of behaving like popular file managers and spreadsheet apps (each column can be resized individually)? This simple logic is what users are familiar with and seems to be what they expect:

• bug 1900675

  Expected results:
  only the column next to it should change, just like in [Microsoft] Excel / [LibreOffice] Calc / spreadsheet programs too

• bug 1854705

  Expected results:
  Same behaviour as in Windows Explorer. The only column that should change width should be the one to the left of the separator. Width change should align 1:1 with cursor movement.

• bug 1850677

  Expected results:
  Exactly follow the mouse pointer as in previous versions and any other program

• bug 1868163

  Expected results:
  each column size has to be resizeable on it's own.

• bug 1885233

  Expected results:
  Each column width adjustment, and only that column setting, should track the mouse.

• bug 1902234

  Actual results:
  When one column width is […] changed, the other columns are also changed. I can not change the column width Individually.
  Expected results:
  column widths should be change […] individually.

• bug 1860593

  Expected results:
  Only the column I tried to adjust should change sizes. Other columns should stay the same width as they were.

Comment 22

[Alessandro Castellani [:aleca]]

Please, don't use bugzilla as a discussion forum, the conversation here should be exclusively about code fixes and reproducible steps.
Also, no need to list all the duplicates in a reply, it makes your message look a bit spammy.

Saying "don't reinvent the wheel and use the simple logic like Excel" it's not very nice.
From the way you wrote it, it seems that you're implying that we're making things complicated on purpose and we're not "just" fixing it with something simple.
This is a very uneducated guess that ignores the complexity of columns resizing and the whole widget.
File managers and spreadsheets scroll horizontally, so the columns only have to deal with a fixed width and not care about overflowing.
We don't have horizontal scrolling on purpose for readability and usability reasons, so we need to enforce a fixed max width to the whole widget and shrink each column to make them fit, but still maintain their % size in relation to all other columns.

As I originally reported, the current implementation is not optimal, with various resizing issues:

• When multiple columns have been resized (which means each column now has a inline width set to it), trying to expand a single column when there's not enough space in the thread pane, fails.
• When the thread pane resizes, and other columns have been resized, only the last column expands or contracts, instead of having a more uniform elastic behaviour.
• When adding extra columns, existing columns don't behave correctly if they've been previously resized with a summed width that it's bigger than the thread pane width.
• Dozens of other tiny little issue that we're most likely not aware of yet.

You're more than welcome to try and help us out by jumping into the code and creating a patch to fix the issue.

Comment 23

[fred]

Avoiding advocacy, I just want to point out that my original bug report was almost the opposite of what Allesandro is concerned with. My report is that the minimum width of a column was changed to be the width of its name, or at least a few characters of it (e.g., "Prior...") rather than allowing the name to be cut short in order to make the column take up less space. Some columns have only a single glyph or a value (like Priority) where only one or two characters need be seen, and the meaning is obvious. If the minimum column width were reduced to 1 character width, then it would save space. Honestly, this doesn't seem to need terribly complex logic. But I'm not a coder.

Comment 24

[Alessandro Castellani [:aleca]]

(In reply to fred from comment #23)

Avoiding advocacy, I just want to point out that my original bug report was almost the opposite of what Allesandro is concerned with. My report is that the minimum width of a column was changed to be the width of its name, or at least a few characters of it (e.g., "Prior...") rather than allowing the name to be cut short in order to make the column take up less space. Some columns have only a single glyph or a value (like Priority) where only one or two characters need be seen, and the meaning is obvious. If the minimum column width were reduced to 1 character width, then it would save space. Honestly, this doesn't seem to need terribly complex logic. But I'm not a coder.

What's your original bug report? I can't find it

EDIT: found it

Comment 25

[chrizilla]

(In reply to Alessandro Castellani [:aleca] from comment #22)
I am sad and very afflicted by your reaction to my comment, which doesn't do me justice. I did not discuss anything. I merely asked a technical question in response to the quoted comments you made in this bug. Nobody can come up with a good idea if questions are stifled. Maybe I could have found a good idea/solution if I was allowed to ask why TB shouldn't behave like the other programs mentioned by users in comment #21. And I also don't think it's fair to blame me for responding to an issue you raised multiple times in this bug.

With regards to the user quotes: It took me quite some time to collect and aggregate them all in one place. I thought it would be a helpful contribution for everyone to quickly see the expectations of users without having to go through all duplicate bug reports. I already distilled user comments into an aggregate summary elsewhere (bug 1889259) and it was appreciated there. I don't know why it's not appreciated this time, but instead even being collapsed! The only difference I see between there and here is that the user echo in bug 1889259 is more inline with planned changes and the user echo in comment #21 apparently is not. But that wouldn't be a reason to hide the user echo. (Quite to the contrary!)

I'm just sad, because it was a lot of (voluntary) work. So if if it's collapsed/hidden, that's honestly truly demotivating for trying to help.

And given that THIS is the place where a "rearchitecture of the columns resizing logic" shall be born, where else but here would be the right place to summarize and take into consideration the user echo in the duplicate bugs of this bug.

Saying "don't reinvent the wheel and use the simple logic like Excel" it's not very nice.

I did not say that !

From the way you wrote it, it seems that you're implying that […]

Please don't imply anything and don't read anything into it that's not there. I asked a technical question. That's all.
Please assume good faith. That's part of the netiquette.

I just asked a technical question which you then proceeded to answering on a technical level (which shows that the question was relevant and had merit). That would have been sufficient. At any rate, I don't think I have merited this personal attack.

Comment 26

[chrizilla]

(In reply to Alessandro Castellani [:aleca] from comment #22)

File managers and spreadsheets scroll horizontally, so the columns only have to deal with a fixed width and not care about overflowing.
We don't have horizontal scrolling on purpose […]

At the time of comment #21 horizontal scrolling (bug 381821) was not WONTFIXED yet, so it was not clear that this is an absolute no-go.
But horizontal scrolling is not required to implement the behviour users ask for in comment #21, because ...

so we need to enforce a fixed max width to the whole widget

... overflow-x: hidden could be used instead.
This achieves the behaviour displayed in the GIF in comment #19.
As an example, the popular "Total Commander" file manager also works this way (no horizontal scrollbar, overflow-x hidden).

and shrink each column to make them fit, but still maintain their % size in relation to all other columns.

The way I read all the "expected results" in comment #21, this proportional shrinking is exactly what users don't want. They all said something to the effect of

When one column width is […] changed, the other columns are also changed. I can not change the column width Individually.
Column widths should be change[able] individually.

I had only tried to highlight this for consideration. I would have thought that it's important to have an open ear for them.
But anyway, given the reaction in comment #22 I'll refrain from further trying to contribute to the resolution of this issue.