Comment 1 Linn 2023-04-18 14:43:47 CEST

When solving this bug, there are a few features we would like to have:

 1) The table shouldn't be able to become too wide, e.g. it shouldn't disappear out of frame and we should not get scrollbars.

 2) The columns should adjust their width dynamically to the content, i.e. columns with wider content should get a bigger slice of the total width, but all columns should fit into the table.

 3) If the content of a cell is too wide to fit into the table, the content should be truncated.


Ideally, the found solution should have all these features, but if that isn't possible in the timeframe we have, we should look for a solution that fulfils these features well enough.

Comment 2 Linn 2023-04-18 16:36:28 CEST

Regarding the truncation of cell content, there are a few things that has been considered:

* When truncating usernames with a prefix (e.g. domain@user) on the Sessions page, if the ellipsis is placed at the end of the line it is a big risk of obstructing the relevant username, especially if the prefix is long. Worst-case scenario is where the prefix is so long that every row of the table has the same text showing in the username column.

  Currently, it seems like there is no way to put the truncation anywhere else than the end of the line, but in the future we might want to truncate usernames at the start of the line or in the middle of the line.


* On the Subcluster page, the agents for each subcluster are shown in a space separated list. The default behaviour for tables is that spaces allow text to wrap in the cell, meaning that all agents in the list are shown and can be searched for when using ctrl+F. If the agent list is truncated, hidden agents can still be searched and matched with, but no highlighting will be shown.

  We likely wont be keeping the ctrl+F-friendly overview of the agent list on this page, to keep things consistent with other pages where too long content is truncated. To see the full list of agents, the list is shown in the popup shown when clicking the subcluster, as well as on the Load page.

Comment 3 Linn 2023-04-19 14:19:13 CEST

We have found a few different options, neither of which is an ideal solution:

* Default table behaviour: Columns are dynamic, but the table can get too wide and truncation is not possible.

* Fixed table layout: Table has correct width and truncation is possible, but columns are not dynamic.

* Fixed columns(1): Given that the correct styling has been applied, the table has correct width and truncation is possible, but columns are not dynamic. The biggest downside is that we don't get a good fallback for unstyled tables. This increases the possibility for future mistakes.

* JavaScript: Would be possible to get all criteria fulfilled, but would take more time than the other options.

(1) This alternative makes some columns get a fixed width, while other columns are free to use the rest of the available space. table-layout: fixed; is not used in this alternative.

Comment 4 Linn 2023-04-21 09:15:54 CEST

We chose to go forward with the fixed table layout method - we value having a stable table width more than the cells being dynamic. It also has a reasonable time scope and it is straightforward to make this the fallback behaviour for tables.

Comment 7 Linn 2023-04-21 10:27:56 CEST

Checked in Firefox, Chrome and Safari, and the table uses its fixed column widths and truncates on overflow without the table itself getting too wide. Marking as resolved.

Comment 8 Linn 2023-04-25 14:36:11 CEST

The fix for this bug breaks the rounding on our tables in Safari. Reopening.

Comment 10 Linn 2023-04-26 14:47:23 CEST

Tested on Firefox, Epiphany and Safari, and the rounding of our tables now works. 

However, note that there is some kind of rendering bug in Safari that makes the first or last table header appear to be divided by a line from the other table header. The size of the browser window affects whether it's the first or the last <th> that gets this divider. This is issue is not addressed in this bug.

Marking as resolved.

Comment 11 Linn 2023-04-27 09:31:14 CEST

There are still some corner cases left to be fixed: 

* The background of the first row of the table also gets rounded corners

* The rounding does not work properly if there are other elements than <thead> or <tbody> last in the table

Comment 15 Linn 2023-05-02 09:36:52 CEST

The notes in comment 11 have now been taken care of:

> * The background of the first row of the table also gets rounded corners
This is not the case any more, checked looking up a non-existing username under System Health.


> * The rounding does not work properly if there are other elements than <thead> or <tbody> last in the table
The CSS have been changed to match on the last element of the set (thead, tbody, tfoot), so their exact order is no longer an issue. A similar rule was added to match on the first of the set of elements as well.

Note that the table rounding for WebKit browsers only works partially - the top corners get rounded, but not the bottom corners. This is because there is an empty <tbody> (containing only whitespaces) that matches the rule for bottom rounding. Using :empty will solve this in the future, and this has been added to futureproof the solution.
https://developer.mozilla.org/en-US/docs/Web/CSS/:empty

Comment 16 Samuel Mannehed 2023-05-03 17:01:29 CEST

Acceptance criteria
-------------------

> * The solution should work in all major browsers
>    - If not possible, there should be a fallback behaviour for incompatible browsers

Works well, tested on Chrome and Firefox on Fedora 37, Edge on Windows 10, and Safari on macOS 13.3.

> * Tables should always fit into Web Admin's graphical container
>    - Scroll bars should not be triggered
>    - Text for long entries should be truncated without having any line breaks in the cell

They do, and it looks very robust.

> * The width of the columns should look reasonable, e.g. not too cramped, excessively wide or just generally out of place

They look good, things are nice and airy. I get the feeling that things are well thought trough, the right columns get the most space.

> * The columns should have some extra space to account for slightly variable content width

Yep!

Documentation
-------------

All important decisions are well documented here in bugzilla. Nice!

Commits
-------

Code looks good. Most comments in the commit-mailinglist have been addressed (one minor comment remains for r40145).

All good, closing!

Comment 17 Linn 2023-05-04 13:24:35 CEST

(In reply to Linn from comment #2)
> Regarding the truncation of cell content, there are a few things that has
> been considered:
> 
> * When truncating usernames with a prefix (e.g. domain@user) on the Sessions
> page, if the ellipsis is placed at the end of the line it is a big risk of
> obstructing the relevant username, especially if the prefix is long.
> Worst-case scenario is where the prefix is so long that every row of the
> table has the same text showing in the username column.
> 
>   Currently, it seems like there is no way to put the truncation anywhere
> else than the end of the line, but in the future we might want to truncate
> usernames at the start of the line or in the middle of the line.

The issue about important parts of names being obscured by the truncation has been moved to bug 8147.

Comment 19 Linn 2023-05-04 17:06:50 CEST

Updated the rule for WebKit table rounding workaround to be more readable. Tested in Epiphany and could see that rounding worked as intended on both empty tables and tables with data in it.

These tables will be "tested automatically" as we continue working on Web Admin, so this specific bug does not need to be retested for now.