664038 - Tbpl wraps bottom-right summary contents unnecessarily (from adding a new column?) when window width increases

Status: RESOLVED FIXED

(Tree Management Graveyard :: TBPL, defect)

Description

[Daniel Holbert [:dholbert] (vacation until Jun 23)]

Attachment: screenshot of bug

STEPS TO REPRODUCE:
 1. Load tbpl
 2. Click a completed log for Android Opt Mochitest-2
     --> Note that the summary at bottom-right has 5 rows of output
 3. Make the window wider.

ACTUAL RESULTS:
An chunk of the output inexplicably ends up wrapping into a newline in a second column (even though it fit perfectly well before), making it harder to read.

See attached screenshot & screencast.

Comment 1

[Daniel Holbert [:dholbert] (vacation until Jun 23)]

Attachment: screenshot of expected rendering (no wrapping) in skinnier window

Comment 2

[Daniel Holbert [:dholbert] (vacation until Jun 23)]

Attachment: screencast of bug

Here's a screencast of the bug, showing both the wrapping vs. no-wrapping renderings as the window width changes.

Comment 3

[Arpad Borsos [:Swatinem]]

The culprit is the multi-column layout. column-width acts like min-width and the browser fits whole numbers of columns there that are at least 240px wide.
So what width is needed so that the columns don’t wrap? As far as I know there is no way to make the width auto.

Comment 4

[Daniel Holbert [:dholbert] (vacation until Jun 23)]

Why make a new column at all in this case?  We clearly don't need one...

Comment 5

[Arpad Borsos [:Swatinem]]

-moz-column-width is responsible for that. I don’t know how we can make that behavior more predictable/controllable.

Comment 6

[Daniel Holbert [:dholbert] (vacation until Jun 23)]

Well more generally, why do we want -moz-column applied on that region at all?  It seems like that'd only be useful there if we had more content than available height (>6 lines), and from some quick clicking around tbpl, I can't find any job where that's the case.  So with our current tbpl configuration, it seems (to me at least) that -moz-column is only hurting us, and never helping us.

Alternately, if we want to keep moz-column, I agree that we just need to increase the minimum column width, as noted in comment 3.  (As you say, it's a bit of a stab in the dark without any magic "auto" value, but it'd at least be an improvement if we upped the value.)

Comment 7

[Markus Stange [:mstange]]

(In reply to comment #6)
> Well more generally, why do we want -moz-column applied on that region at
> all?  It seems like that'd only be useful there if we had more content than
> available height (>6 lines), and from some quick clicking around tbpl, I
> can't find any job where that's the case.

Indeed, looks like that's the case nowadays. Back when I added the columns it was very common to have two or three of them for some Talos builds.

> Alternately, if we want to keep moz-column, I agree that we just need to
> increase the minimum column width, as noted in comment 3.  (As you say, it's
> a bit of a stab in the dark without any magic "auto" value, but it'd at
> least be an improvement if we upped the value.)

I'll give this a shot.

Comment 8

[Markus Stange [:mstange]]

Attachment: 40em ought to be enough for anyone

Comment 9

[Arpad Borsos [:Swatinem]]

Comment on attachment 540014 [details] [diff] [review]
40em ought to be enough for anyone

Review of attachment 540014 [details] [diff] [review]:
-----------------------------------------------------------------

Comment 10

[Markus Stange [:mstange]]

I actually did check this in, ages ago.
https://hg.mozilla.org/webtools/tbpl/rev/ebeeaa9e8294