Tested the issue on chrome Stable #54.0.2840.71, Canary 56.0.2900.0 in Ubuntu 14.04 and was able to reproduce the issue.

This is a Non-Regression issue since seeing this from M35 #35.0.1898.0, Making the status to Untriaged so that the issue would get addressed.

Note : Able to reproduce the issue in MAC 10.12 and Windows 10.0

Thank you.

On second thought, I'm not sure if this is really a bug.

For fractions, a numberstring in base 36 can be longer then a numberstring in base 10. 

Like 3 + 1/3 in base 3  = 10.1 while in base 10 it can only be estimated (3.33333)

It's probably a (not) rounding issue, a behavior that differs from Firefox and other JS engines. 

Is this something that works according to spec?

This is not a bug. 4/3 in base 3 is indeed 1.1. However, Javascript uses IEEE 754 floating point numbers, which are base 2. Storing 1/3 in base 2 will experience rounding errors.

The spec (20.1.3.6 Number.prototype.toString, step 7) says:

Return the String representation of this Number value using the radix specified by radixNumber. Letters a-z are used for digits with values 10 through 35. The precise algorithm is implementation-dependent, however the algorithm should be a generalization of that specified in 7.1.12.1.

So differing from Firefox does not surprise me.

Still the outcome of 0.19155912401454667).toString(11) does suggest a significance or precision that isn't there. (919 significant figures)

Isn't that a bug?

This issue sounds very similar to  Issue 666376  . I don't think there's a spec violation (and one certainly should not read significance into IEEE float digits printed!), but it's possible that the Firefox results are subjectively "better" for users. Safari also outputs the shorter string.

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/21b0dbedfd470b67c47f84428e1af95a506e49e5

commit 21b0dbedfd470b67c47f84428e1af95a506e49e5
Author: yangguo <yangguo@chromium.org>
Date: Thu Nov 24 10:30:19 2016

Reimplement Number.prototype.toString with non-default radix.

The old algorithm produces unnecessary decimal digits. The new one
converts the significand of the input double into an uint64_t to be
just as precise as necessary.

R=tebbi@chromium.org
BUG= chromium:658712 , chromium:666376 

Review-Url: https://codereview.chromium.org/2520363002
Cr-Commit-Position: refs/heads/master@{#41255}

[modify] https://crrev.com/21b0dbedfd470b67c47f84428e1af95a506e49e5/src/builtins/builtins-number.cc
[modify] https://crrev.com/21b0dbedfd470b67c47f84428e1af95a506e49e5/src/conversions.cc
[modify] https://crrev.com/21b0dbedfd470b67c47f84428e1af95a506e49e5/test/mjsunit/number-tostring.js
[modify] https://crrev.com/21b0dbedfd470b67c47f84428e1af95a506e49e5/test/webkit/fast/js/number-toString-expected.txt
[modify] https://crrev.com/21b0dbedfd470b67c47f84428e1af95a506e49e5/test/webkit/fast/js/toString-number-expected.txt