When you anticipate a website that needs to use LocalStorage or SessionStorage above a certain amount of characters, the browser saves the content normally in the browser. By accessing the Developer mode and trying to edit the content, what happens is the last part of the saved data is replaced with a "…" character and all other info is lost.
You can no longer edit this data, since most of it is lost and the (web) application is probably broken now.
Steps to Reproduce:
1. Open Safari
2. Visit website that uses local storage and saves a large (over 50 characters or so value) [Better keep Safari in a small viewport]
3. Right click anywhere
4. Click "Inspect Element"
5. Click the "Resources" tab
6. "Click LocalStorage or SessionStorage"
7. Locate a key with a value ending in "…" (chopped to fit screen)
8. Double click the value to edit
9. Click anywhere to save it.
Safari was supposed to present the full data when the user double clicks to edit the key.
Safari presents only the beginning of the data, with a "…" instead of the tailing characters. LocalStorage is edited and the web app is probably broken now.
When double clicking, restore value to the full key, and not simply allow editing with the "…" in place.
Created attachment 304963 [details]
Created attachment 304965 [details]
[Animated GIF] With patch applied
Nice, I noticed this a while back.
Comment on attachment 304963 [details]
r-, for some reason `text-overflow: ellipsis` isn't restored after cancel/commit.
(In reply to comment #4)
> Comment on attachment 304963 [details]
> r-, for some reason `text-overflow: ellipsis` isn't restored after
gets replaced with
Created attachment 305062 [details]
I've tried making <div class=cell-content> editable instead of <td>, but it appeared to be difficult to style to make it look the way <td class=editing> looks now.
I ended up re-creating <div class=cell-content> after every edit.
Created attachment 305138 [details]
As per an offline discussion with Brian, there should be only one code path for creating <div class=cell-content>.
Comment on attachment 305138 [details]
Attachment 305138 [details] did not pass mac-debug-ews (mac):
New failing tests:
Created attachment 305149 [details]
Archive of layout-test-results from ews117 for mac-elcapitan
The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews117 Port: mac-elcapitan Platform: Mac OS X 10.11.6
Created attachment 305203 [details]
Unrelated flaky test. Re-uploading the patch.
Comment on attachment 305203 [details]
View in context: https://bugs.webkit.org/attachment.cgi?id=305203&action=review
> + since it may get removed while editing.
You should mention that div.cell-content is removed because the <td> itself is contenteditable (using the fancy -webkit-user-modify:read-write-plaintext-only), not the inner div.cell-content.
Created attachment 305204 [details]
Comment on attachment 305204 [details]
Clearing flags on attachment: 305204
Committed r214308: <http://trac.webkit.org/changeset/214308>
All reviewed patches have been landed. Closing bug.