UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36

Steps to reproduce the problem:
I am running Google Chrome 52.0.2743.116 (64-bit) on Mac OS X 10.11.6, fairly new MacBook Pro, 16GB RAM.

I open a tab and open http://example.com (so chosen because there will be nothing already in localStorage). I open the developer tools and open the "Console". I run the following JavaScript:

var USE_UNICODE = true;
var PUSH_MANY = true;
function randomString(len) {
    var result = "";
    for (var i = 0; i < len; i++)
        result += String.fromCharCode(USE_UNICODE ?
            Math.floor(Math.random() * 65536) :   /* Entire UCS-2 range */
            65 + Math.floor(Math.random() * 26)); /* A-Z */
    return result;
}
localStorage.clear();
if (PUSH_MANY) { /* Store many long strings, varying size */
    var inuse = 0;
    while (inuse < 4900000) {
        var newSize = Math.floor(Math.random() * 40000);
        inuse += newSize;
        localStorage.setItem("@" + inuse, randomString(newSize));
    }
} else {         /* Store one long string */
    localStorage.setItem("@0", randomString(40000));
}

(Although this program is arbitrary, it mimics the behavior of a real-world application I work on. In my real-world application, the long and variably-sized strings are being generated by the lz-string library.)

I click on the "Application" tab, and click on Local Storage -> http://example.com.

What is the expected behavior?
- The developer tools pane should be able to display long Unicode strings, even malformed ones.
- If the developer tools pane cannot display long Unicode strings, it should not attempt to do so-- it should detect the string cannot be efficiently displayed and hide or truncate it.
- The interface should never lock up for 10+ seconds simply because of the content it was asked to display-- especially without some sort of loading indicator.

What went wrong?
Following the above repro steps, as soon as I open the local storage viewer the Chrome developer pane freezes and GUI-locks. Although no throbber or other indication that work is being performed occurs, the developer pane stops responding to any sort of clicks (it cannot even be closed). During this time I can click on and interact with the top navigation bar (back, reload etc), and I can click on and interact with the page content. Navigating to another domain using the navigation bar is possible but does not unfreeze the Chrome developer pane.

The only way to restore use of the developer pane at this point is to close the Chrome window and open a new window-- although I'd better be careful not to immediately open the developer pane in the same domain where it got into GUI-lock before, because by default it will re-open to the last thing I had open, the local storage viewer, and then it will just lock up again.

Did this work before? N/A 

Chrome version: 52.0.2743.116  Channel: stable
OS Version: OS X 10.11.6
Flash Version: Shockwave Flash 22.0 r0

- The example program generates many long strings but it is sufficient to generate one long string. If you run my sample code above with PUSH_MANY = false, the pane will still lock up for a period of about 50 seconds before displaying (which is not indefinite but still long enough for a reasonable person to give up).
- The developer pane does not appear to struggle in this way if the long strings are ASCII-7. If you run my sample code above with USE_UNICODE=false, it freezes, but only for about eight seconds (which is bad, but a reasonable person might wait that long before assuming something has gone wrong). If you run my sample code with USE_UNICODE=false PUSH_MANY=false, the local storage pane displays instantly.