Bug 178318

Summary: Web Inspector: Storage: values truncated in Local/Session table
Product: WebKit Reporter: Ricci Adams <webkit.org>
Component: Web InspectorAssignee: Devin Rousso <hi>
Status: RESOLVED FIXED    
Severity: Normal CC: bburg, commit-queue, hi, inspector-bugzilla-changes, joepeck, timothy, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: Safari 11   
Hardware: All   
OS: All   
See Also: https://bugs.webkit.org/show_bug.cgi?id=198003
Attachments:
Description Flags
Patch
none
Patch none

Ricci Adams
Reported 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
Attachments
Patch (2.55 KB, patch)
2019-04-01 16:13 PDT, Devin Rousso 		no flags
DetailsFormatted DiffDiff
Patch (7.32 KB, patch)
2019-04-15 23:57 PDT, Devin Rousso 		no flags
DetailsFormatted DiffDiff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.
Blaze Burg
Comment 1 2017-10-15 11:13:07 PDT
Does this reproduce in Safari Technology Preview?
Radar WebKit Bug Importer
Comment 2 2017-10-15 11:13:25 PDT
<rdar://problem/34998581>
Joseph Pecoraro
Comment 3 2017-10-15 14:58:14 PDT
(In reply to Brian Burg from comment #1) > Does this reproduce in Safari Technology Preview? Yes.
Joseph Pecoraro
Comment 4 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.
Devin Rousso
Comment 5 2019-04-01 16:13:25 PDT
Created attachment 366437 [details] Patch
Joseph Pecoraro
Comment 6 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?
Timothy Hatcher
Comment 7 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.
Joseph Pecoraro
Comment 8 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
Ricci Adams
Comment 9 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?
Joseph Pecoraro
Comment 10 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.
Devin Rousso
Comment 11 2019-04-15 23:57:47 PDT
Created attachment 367504 [details] Patch
Joseph Pecoraro
Comment 12 2019-04-16 11:59:25 PDT
Comment on attachment 367504 [details] Patch r=me
WebKit Commit Bot
Comment 13 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>
WebKit Commit Bot
Comment 14 2019-04-16 12:02:30 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.