1851368 - Changing threadTree row height by css destroys scrolling by keys

Status: RESOLVED WONTFIX

(Thunderbird :: Folder and Message Lists, defect)

Description

[Frank Steiner]

Scrolling the message list in the threadPane with arrow keys or PgUp/PgDn doesn't work correctly if the height of the message rows has been changed by some css code.

Usually, when selecting a message in the threadPane with a mouse will give it the blue selection bar. Now scrolling with the arrow keys, will move that selection bar up or down until it reaches the top or bottom of the threadPane window. Pressing the same key again will now scroll the messages by one message so that the selection bar always stays visible, either at the top or bottom and the messages will scroll "through" that bar.
And when scrolling with PgUp/PgDown, the message list will scroll by as many messages fit into the threadPane, but the selection bar will always stay visible at the top or bottom.

This no longer works when the height of the rows in the threadPane is changed by css.

The reason is that there are only three possible row heights and those are defined by fixed numbers in the densityChange() function in about3Pane.js. E.g., if you select View -> Density -> Default, this will be executed in the densityChange function:

  switch (UIDensity.prefValue) {
    case UIDensity.MODE_COMPACT:
      rowClass.ROW_HEIGHT = 26;
      ...

Thus, the row height for the message rows in the threadTree is fixed to 26px. All the calculations for scrolling are then done in tree-view.mjs based on the value of ROW_HEIGHT.

But if the row height is changed to anything else but these 26px by some css code in userChrome.css, the calculation is still done based on 26px and not on the real height that the rows now have. That will make scrolling by keys go wrong.

To reproduce:
Select default density as described above.
Change the height to a larger value by something like:

#threadTree tbody[role] tr { 
  height: 30px!important;
}

and make sure that after restarting the row heights are indeed higher as without the css code.
Now, selecting a message and scrolling down with the arrow down key will make the selection bar move out of the window. It will vanish below the bottom of the threadPane (while still selecting new messages). Scrolling of the messages will start only after 2-3 additional key presses.

Scrolling up with the arrow key will show a different behaviour, i.e., scrolling of the messages will start before the selection bar has reached the top of the window.

Changing the row height to a smaller value, e.g. 20px instead of the default 26px, will invert that behaviour: the bar will vanish at the top of the threadPane, and scrolling down will start before the bar has reached the bottom.

Non-working attempts to fix:
Setting --list-item-min-height doesn't work. It changes the row height of the folderTree but not the threadTee.

Trying to change ROW_HEIGHT in a userscript didn't succeed. I can select the #threadTree and inspect the value of _rowElementClass.ROW_HEIGHT in the console, but I cannot change it.

Possible fixes:
I would propose to either use the calculated height of the tr after css is applied instead of the fixed ROW_HEIGHT values.
If that is too inefficient, it would be nice to have variables in prefs.js (like uidensity.compact.row_height) or css variables (like --uidensity-compact-row-height) and use their values (if defined) instead of the fixed values, so that users can easily adjust the row height to the desired values.

thunderbird allows restyling everything by css (and it has gotten way easier in TB 115 due to the html instead of xul), so it would be strange if it was not possible for the threadPane just because row height values are fixed to some pre-defined values that cannot be changed.

Comment 1

[Alessandro Castellani [:aleca]]

The tree items need to have a fixed height because that's needed for the scrolling virtualization.
If you change it, everything breaks.
We have an ongoing exploration to see if it's possible to recalculate the scrolling threshold height when the content changes in bug 1799510, but it's not a priority.

Comment 2

[Frank Steiner]

I understand! But the height can take different values as one can change them by chosing a different density. So, does the scrolling only work with exactly these fixed values 18/26/32px as defined in about3Pane.js for some reason? Or could they also be defined in variables in pref.js so that they are once read during startup? This way they could stay fixed throughout the thunderbird session, but they could be different than only 18/26/32.