Bug 178318 - Web Inspector: Storage: values truncated in Local/Session table
Summary: Web Inspector: Storage: values truncated in Local/Session table
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (show other bugs)
Version: Safari 11
Hardware: All All
: P2 Normal
Assignee: Devin Rousso
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2017-10-14 17:40 PDT by Ricci Adams
Modified: 2019-05-17 14:41 PDT (History)
7 users (show)

See Also:

Attachments
Patch (2.55 KB, patch)
2019-04-01 16:13 PDT, Devin Rousso 		no flags Details | Formatted Diff | Diff
Patch (7.32 KB, patch)
2019-04-15 23:57 PDT, Devin Rousso 		no flags Details | Formatted Diff | Diff
Show Obsolete (1) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Ricci Adams 2017-10-14 17:40:00 PDT 
When a Value in the Local Storage / Session Storage is long and truncated, Both "Copy Value" and "Copy Table" copy the truncated string with trailing ellipses, not the actual value.

Steps to Reproduce:
1. Serialize a large object via JSON.stringify and store it via window.localStorage
2. View Local Storage in Web Inspector
3. Attempt to copy the value via "Copy Table" or "Copy Row"

Expected Result:
Actual value is copied

Actual Result:
Truncated value is copied with trailing ellipses
Comment 1 BJ Burg 2017-10-15 11:13:07 PDT 
Does this reproduce in Safari Technology Preview?
Comment 2 Radar WebKit Bug Importer 2017-10-15 11:13:25 PDT 
<rdar://problem/34998581>
Comment 3 Joseph Pecoraro 2017-10-15 14:58:14 PDT 
(In reply to Brian Burg from comment #1)
> Does this reproduce in Safari Technology Preview?

Yes.
Comment 4 Joseph Pecoraro 2017-10-15 15:06:43 PDT 
DOMStorageContentView.prototype._populate creates DataGridNodes with truncated values (length 200). Copy Row then copies the DataGridNode's data values, which is this truncated string. Likewise double click to edit gets the truncated value.
Comment 5 Devin Rousso 2019-04-01 16:13:25 PDT 
Created attachment 366437 [details]
Patch
Comment 6 Joseph Pecoraro 2019-04-01 16:31:21 PDT 
Comment on attachment 366437 [details]
Patch

I believe this was done for some performance reason (when very large values are stored in the table. Does this regress something?
Comment 7 Timothy Hatcher 2019-04-15 10:21:30 PDT 
(In reply to Joseph Pecoraro from comment #6)
> Comment on attachment 366437 [details]
> Patch
> 
> I believe this was done for some performance reason (when very large values
> are stored in the table. Does this regress something?

Joe is right, that is why.
Comment 8 Joseph Pecoraro 2019-04-15 11:03:39 PDT 
Comment on attachment 366437 [details]
Patch

Clearing review until:

    (1) we find a solution that solves both the performance and selection issue
    (2) we make a decision that selection is more important than performance
Comment 9 Ricci Adams 2019-04-15 15:59:06 PDT 
This still affects my workflow all the time. Could the full value be re-fetched in response to a Copy command?
Comment 10 Joseph Pecoraro 2019-04-15 16:29:40 PDT 
(In reply to Ricci Adams from comment #9)
> This still affects my workflow all the time. Could the full value be
> re-fetched in response to a Copy command?

That is a good idea! We should be able to override Copy in this table to get the full value and not the truncated string being displayed.
Comment 11 Devin Rousso 2019-04-15 23:57:47 PDT 
Created attachment 367504 [details]
Patch
Comment 12 Joseph Pecoraro 2019-04-16 11:59:25 PDT 
Comment on attachment 367504 [details]
Patch

r=me
Comment 13 WebKit Commit Bot 2019-04-16 12:02:29 PDT 
Comment on attachment 367504 [details]
Patch

Clearing flags on attachment: 367504

Committed r244350: <https://trac.webkit.org/changeset/244350>
Comment 14 WebKit Commit Bot 2019-04-16 12:02:30 PDT 
All reviewed patches have been landed.  Closing bug.