Thanks for filing the issue!

Unable to reproduce the issue on reported chrome version 66.0.3359.170 using Windows 10 with the below mentioned steps.
1. Launched chrome
2. Downloaded 1.zip and extracted it.
3. Dragged and dropped the test file present in the folder.
We were able see the text is centred. Attaching the screen cast of the same.

@Reporter: Could you please have a look at the screen cast and let us know if anything missed from our end. Any further inputs from your end may be helpful.

Deleted: 842489.mp4 3.5 MB

	842489.mp4 3.5 MB View Download

I'm able to reproduce the issue on Windows 8.1 using Chrome 63.0.3239.132 x64 and on Windows 7 using Chrome 66.0.3359.170 x32.

I would like to upload a screencast for the reference, but it exceeds the 10MB max file size, so I uploaded it to youtube instead. Here is the link: https://www.youtube.com/watch?v=b-FlHd42J0w

Please take a look at the uploaded screencast.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Able to reproduce the issue on reported chrome version 66.0.3359.170 and on latest chrome 68.0.3430.0 using Windows 7 & 10, Mac 10.13.1 and Ubuntu 14.04. 
 
Same behavior is seen on M60(60.0.3112.113) hence considering it as non-regression and marking it as Untriaged.
Thanks! 

You're painting 2,000,001 characters in 72px on a line, which overflows our computation limit.

Tested on Firefox and Edge, neither browsers render anything at all, I don't think there's much things we can do here.

Pass by to the area experts in case they have any further feedback, but please add comments if you have any.

Re C#7, I cannot see why it is a problem. From my point of view, the algorithm is simple:

1. Measure the width of the string (suppose each character is 100 pixels, it still can be stored in a single 32-bit integer)
2. Divide the with by 2
3. Translate the text by that value to the left

IMHO, the fact that other browsers don't support it should not be a hindrance for implementing it in Chrome. I mean, few millions characters is not so much that it can be considered as an extreme edge case, and also it is far away from maximum string length.

@hakerh403@gmail.com, your solution only works for mono-spaced fonts. Currently Chromium measures the length of the entire string for horizontal centering (https://cs.chromium.org/chromium/src/third_party/blink/renderer/modules/canvas/canvas2d/canvas_rendering_context_2d.cc?g=0&l=858) as it cannot assume that all characters are of equal width.

I understand the floating point rounding error that is involved in computing width of string for non-monospaced font glyphs.

However, from logical point of view, it's not clear to me what the hindrance for resolving this issue is. If rendering context is able to draw a string, how it's unable to determine string's length of the pixel precision? The drawn string has some width than can be expressed in amount of pixels it takes. Rendering context is able to draw it, but it's unable to determine it's width...?

If I get it correctly, the internal operations used in the algorithm for determining string's width is different than algorithm that draws the string. The first algorithm is faster and uses more optimized techniques, but results are inaccurate.

One solution that I think is feasible is to virtually draw all glyphs internally, calculate pixel width of the whole drawn string, and use that value to translate the text when center-aligning in original canvas.

The offscreen "#" are not actually rendered, once the measuring algorithm runs the renderer decides where to begin actually drawing characters. With millions of characters small floating point errors can propagate, causing the renderer to effectively start with the wrong part of the string. If the renderer actually moved ALL the way to the left and started rendering millions of "#" into VRAM the string would still be off center because of the exact same float rounding error (essentially the horizontal advance, being ever so slightly off, would propagate after drawing a million characters).
  Yesterday we experimented with `double` precision on this algorithm, unfortunately there are many APIs that would also need to change. And then the algorithm would still break for a *billion* characters, etc. 
  Considering the cost of a fix (greater memory footprint for all text rendering throughout the browser), it's not worth fixing this for narrow use cases.