Closed Bug 1032495 Opened 12 years ago Closed 12 years ago

Summaries for bug suggestions should wrap rather than being truncated

Categories

(Tree Management :: Treeherder, defect, P1)

Product:
Tree Management
Component:
Treeherder
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: emorley, Assigned: jfrench)

References

(
URL
)

Details

1) Make the browser window half the screen width (eg snap to 50% left) 2) Open Treeherder to a tree with unclassified failures, and select a failed job 3) On the "failure summary" tab, look for a bug summary that is longer than the width of the panel, if one not found, repeat from #2 but with another failed job (the marionette ones are good for long bug summaries). 4) Try to read the full summary of this bug, as quickly as possible (so as to confirm if it matches the failure line for which it has been suggested) and ideally without using the mouse (ie no mouseover). Expected: Full bug summary visible, like TBPL, by wrapping the summary when needed. Actual: Bug summary truncated with "..." and the full summary only visible on mouseover. Blocking since this reduces speed of failure classification compared to TBPL.
Priority: -- → P1
I see the same thing. I think the nowrap class just needs to be pulled from this line. https://github.com/mozilla/treeherder-ui/blob/master/webapp/app/plugins/failure_summary/main.html#L7
I've tested the fix and it appears to be fine. I have the change ready to push and open a PR, but I am getting somewhat crazy results when I grunt build . All sorts of unrelated changes in ./tmp/concat and ./dist. I need to check in with mdoglio or camd tomorrow on that before I open the PR. After that it should be ready. If it's blocker and critical path, obviously anyone feel free to push their own fix, if it's needed before that occurs.
Assignee: nobody → tojonmz
URL: https://treeherder.mozilla.org
Status: NEW → ASSIGNED
Thank you :-)
Thinking about it, in the absence of automatic grunt builds on the back end, probably the best practice is to always push at a minimum two commits: one for the real work, the other for my local grunt build(s) with each iteration. Then we can actually see the real work, and they can get squashed (or not) in the merge. I will check with camd this morning and open a PR shortly. I agree with the notion of having the grunt builds be automatic and on the back end. At least as a newbie, it seems it would make commit history in master so much cleaner.
(In reply to Jonathan French (:jfrench) from comment #4) > I agree with having the grunt builds be automatic and on the back end. edmorley has kindly entered this as 1033415.
This has been pushed to both stage and production, and I've tested it with failed jobs in central and inbound with narrow failure panels, and it appears to be working fine. Ed feel free to have a look at some jobs and let me know if it looks good to you. https://treeherder.allizom.org (stage) https://treeherder.mozilla.org (prod)
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
That looks good - thank you :-)
You need to log in before you can comment on or make changes to this bug.