DevTools: untruncate links on copy

third_party/WebKit/Source/devtools/front_end/workspace/UISourceCode.js

Index: third_party/WebKit/Source/devtools/front_end/workspace/UISourceCode.js
diff --git a/third_party/WebKit/Source/devtools/front_end/workspace/UISourceCode.js b/third_party/WebKit/Source/devtools/front_end/workspace/UISourceCode.js
index 4fa5b554791586c37976b94c5f63d1532deb9929..75b258369e59b02b2194e013c9913cc033b90d07 100644
--- a/third_party/WebKit/Source/devtools/front_end/workspace/UISourceCode.js
+++ b/third_party/WebKit/Source/devtools/front_end/workspace/UISourceCode.js
@@ -661,10 +661,11 @@ Workspace.UILocation = class {
   }
 
   /**
+   * @param {boolean=} skipTrim
    * @return {string}
    */
-  linkText() {
-    var linkText = this.uiSourceCode.displayName();
+  linkText(skipTrim) {
+    var linkText = this.uiSourceCode.displayName(skipTrim);

[allada, 2017/03/28 01:13:08]

I'm worried about data urls. Can we do a test to see what happens if we have a
few hundred 20k data urls get logged and returned by this method?

[luoe, 2017/03/31 21:35:21]

Testing methodology: make 10k logs of the sample text in the console, select all
messages, ctrl-C, and compute time spent on _selectedText()

In the worst case conditions, a truncated string is 10k characters long (we have
a MaxLengthToIgnoreLinkifier that bails out).

Sample: data url of length 10k (trimmed to 150 currently)
- 483ms before, 788ms after patch

Sample: regular text of length 150
- 361ms before, 409ms after patch

In the worst case, copying hundreds of MB of text takes a few hundred more ms. 
The average case  does not regress by much.

[allada, 2017/03/31 23:17:33]

Acknowledged.

     if (typeof this.lineNumber === 'number')
       linkText += ':' + (this.lineNumber + 1);
     return linkText;