Hmm, looks like this also affects Views platforms.

Deleted: Screen Shot 2017-09-13 at 12.52.31 PM.png 14.1 KB

	Screen Shot 2017-09-13 at 12.52.31 PM.png 14.1 KB View Download

Are you reusing code?

Yes: gfx::ElideFilename(), which is also used in the current shelf. I think it's a bug in that code. I would guess that it wasn't noticeable on the old shelf because the text drawing doesn't clip, so if the text was too long it'd just keep going a few pixels beyond where it should have stopped.

This line is suspicious:

https://chromium.googlesource.com/chromium/src/+/edb9daff1efe0710675729e4409a9f94845971b8/ui/gfx/text_elider.cc#208

Hey bungeman@. I'm wondering if you have any thoughts on this crbug (or know who would?). It describes a cross-platform issue where |gfx::ElideFilename(string, font_list, max_width)| can return a string that's wider than |max_width|. Here's a CL that shows the problem via unit tests:

https://chromium-review.googlesource.com/c/chromium/src/+/756495

The immediate cause is that RenderText only accepts integral sizes, so ElideFilename() ceil()s the widths of the base part of the filename and the extension part before asking it to elide each. The existing tests fail if I change this, because they just check that (pseudocode):

    ElideFilename(string, StringWidthF(hand_elided_string)) == hand_elided_string;

If the ceil()s were floor(), ElideFilename may return a string that's a bit shorter than the input. I'm not sure whether to think of this as a test problem, if there's a way to use a RenderText with a floating point width, or if there's a totally different/better way of looking at it. Cheers!

Unfortunately, I don't know much about gfx::RenderText other than that it needs a bit of cleanup with regard to some assumptions that it makes, including those enforced by tests. Many of these assumptions probably made sense at some point in the past, but many of them should probably be revisited now. If it fixes an actual bug to change this to 'floor' then the test should probably be updated to match the better behavior. However, you should probably ask the owner, who I believe is msw@.

Ideally, we'd increase RenderText and text_elider support for floating point widths; there's some, but it's likely incomplete. I'm not actively working in this area, but happy to review CLs. I also recommend fade eliding (like tab titles) instead of using ellipses, if that's acceptable for this feature (it shows more text, avoids costly width determination, avoids Bidi eliding issues, looks nice, etc.)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1598ab7482fb883d18b5522e762b77c70da439c3

commit 1598ab7482fb883d18b5522e762b77c70da439c3
Author: Sidney San Martín <sdy@chromium.org>
Date: Tue Nov 07 21:57:27 2017

Subtract the default line fragment padding from the available space for the filename.

Bug:  764546 
Change-Id: I2cd2fb64fbcdc4e075f52ef2da412255751706da
Reviewed-on: https://chromium-review.googlesource.com/757232
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Sidney San Martín <sdy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#514614}
[modify] https://crrev.com/1598ab7482fb883d18b5522e762b77c70da439c3/chrome/browser/ui/cocoa/download/md_download_item_view.mm

Tested the issue on mac 10.12.6( by enabling MD downloads), Win-10 and ubuntu 14.04 using latest chrome version #64.0.3262.0 as per comment #0 and #1.
Attached screenshots for reference.

Observed that download button have a truncated title as expected on OS-Mac and OS-Linux. 
Whereas on OS-Win, file name before the file extension gets truncated, and the file extension also gets truncated. As a result there are two ellipses in the button title as the reported version #63.0.3213.0

sdy@ - Could you please confirm the behaviour of OS-Win and also please confirm the fix.

Thanks...!!

Deleted: 764546@mac.png 1.3 MB

	764546@mac.png 1.3 MB View Download

Deleted: 764546@linux.png 94.7 KB

	764546@linux.png 94.7 KB View Download

Deleted: 764546@Win10.JPG 163 KB

	764546@Win10.JPG 163 KB View Download

On further investigation, I think the Mac case was mainly caused by not accounting for implicit padding in the label. The bug I described is real but maybe the Views shelf is also affected by something more blatant? Filed issue 782830.

Re. #10, yep, that looks right (and I filed issue 782830 for Windows).