I think this is the CSS that tries to cut off the titles interacting weirdly with other table CSS.

For tasks with very long titles, we try to make the browser show as much text as will fit, but not stretch the table and not wrap onto the next line. This is deceptively complicated, and the best way I've found to do this is quite a mess and ends up looking like this:

<div class="outer">
  <span class="inner">
    (Actual Content Goes Here)
  </span>
  (A Single Nonbreaking Space)
</div>

This is basically some 1994 markup where   was how you laid things out on the web. The actual implementation is in AphrontTableView::renderSingleDisplayLine().

Even if this behavior wasn't acting weirdly, it wouldn't accomplish the desired result (being able to read the task summaries) since it would prevent the table from scrolling.

A better fix is maybe:

• stop using this;
• instead, do a normal, hard-coded, glyph-based cutoff;
• let the table scroll if the cutoff proves too restrictive at display time.

In conjunction with this, it might be worth adjusting the numbers for when we fallback to the parents/children-only view and the "never mind, too much stuff, go look at the list" view, although a fallback would probably be worse than a scrollable table in this case.

Until this is fixed, a workaround is to select Search → Search Subtasks in the panel, to get a result list of subtasks.

Generally, the use case here (a very large number of subtasks with little real information in each) feels like something we could accommodate better in the future in a different way -- maybe via T4348, or Nuance, or whatever comes of T9652 in the future. These tasks are generally smaller and more granular than Maniphest works best with, and more closely resemble the work described in T4348 (go through a codebase file-by-file and do some sort of manual thing to each file -- here, it isn't a codebase being operated on directly, but the work seems similar). However, tools here are likely far away and using Maniphest for this is just slightly off-label; I think it's still a use case we should try to accommodate as well as we reasonably can, especially until we have alternatives.

I think this should work better at HEAD of master now -- let us know if you're still seeing issues after updating. Thanks for the report!