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

RESOLVED FIXED

Status

RESOLVED FIXED
7 years ago
4 years ago

People

(Reporter: dholbert, Unassigned)

Tracking

Trunk
All
Linux

Details

(URL)

Attachments

(4 attachments)

(Reporter)

Description

7 years ago
Created attachment 539059 [details]
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.
(Reporter)

Updated

7 years ago
Summary: Tbpl wraps unnecessarily → Tbpl wraps bottom-right summary contents unnecessarily (from adding a new column?) when window width increases
(Reporter)

Updated

7 years ago
Attachment #539059 - Attachment description: screenshot → screenshot of bug
(Reporter)

Comment 1

7 years ago
Created attachment 539062 [details]
screenshot of expected rendering (no wrapping) in skinnier window
(Reporter)

Comment 2

7 years ago
Created attachment 539065 [details]
screencast of bug

Here's a screencast of the bug, showing both the wrapping vs. no-wrapping renderings as the window width changes.
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.
(Reporter)

Comment 4

7 years ago
Why make a new column at all in this case?  We clearly don't need one...
-moz-column-width is responsible for that. I don’t know how we can make that behavior more predictable/controllable.
(Reporter)

Comment 6

7 years ago
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.)
(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.
Created attachment 540014 [details] [diff] [review]
40em ought to be enough for anyone
Attachment #540014 - Flags: review?(arpad.borsos)
Comment on attachment 540014 [details] [diff] [review]
40em ought to be enough for anyone

Review of attachment 540014 [details] [diff] [review]:
-----------------------------------------------------------------
Attachment #540014 - Flags: review?(arpad.borsos) → review+
I actually did check this in, ages ago.
https://hg.mozilla.org/webtools/tbpl/rev/ebeeaa9e8294
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
(Assignee)

Updated

4 years ago
Product: Webtools → Tree Management
(Assignee)

Updated

4 years ago
Product: Tree Management → Tree Management Graveyard
You need to log in before you can comment on or make changes to this bug.