Closed Bug 664038 Opened 14 years ago Closed 12 years ago

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

Categories

(Tree Management Graveyard :: TBPL, defect)

All
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: dholbert, Unassigned)

References

()

Details

Attachments

(4 files)

Attached image 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.
Summary: Tbpl wraps unnecessarily → Tbpl wraps bottom-right summary contents unnecessarily (from adding a new column?) when window width increases
Attachment #539059 - Attachment description: screenshot → screenshot of bug
Attached video 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.
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.
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.
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
Closed: 12 years ago
Resolution: --- → FIXED
Product: Webtools → Tree Management
Product: Tree Management → Tree Management Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: