14337 2011-09-30 00:34:04 +0000 Drag-and-drop / undo manager interaction 2016-03-25 05:08:05 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED WONTFIX P3 normal Unsorted 1 ian rniwa annevk ian mike rniwa contributor oldest_to_newest 57541 0 ian 2011-09-30 00:34:04 +0000 57542 1 ian 2011-09-30 00:35:45 +0000 Ryosuke, can you advise regarding what should be done about the red text here?: http://www.whatwg.org/specs/web-apps/current-work/complete.html#initiate-the-drag-and-drop-operation How do I adjust the text to work with your new model? 57598 2 rniwa 2011-09-30 21:04:59 +0000 So I think in step 4.1.3. where it says "Insert the actual data of the first item in the drag data store item list to have a drag data item type string of "text/plain" and a drag data item kind that is Plain Unicode string into the text field or editing host or editable element in a manner consistent with platform-specific conventions (e.g. inserting it at the current mouse cursor position, or inserting it at the end of the field)." The insertion should be implemented as automatic transaction, and the UA should fire transaction event at the end of the insertion as specified in my working draft. 57639 3 ian 2011-10-02 16:39:18 +0000 It's more than that, though. Literally every DOM manipulation done to the document between the start of the drag and drop operation and the end of it ends up in the browser's undo transaction history, at least in IE. that is whether it was done by script, or indeed anything else. 57720 4 rniwa 2011-10-03 19:02:37 +0000 (In reply to comment #3) > It's more than that, though. Literally every DOM manipulation done to the > document between the start of the drag and drop operation and the end of it > ends up in the browser's undo transaction history, at least in IE. that is > whether it was done by script, or indeed anything else. I see. I wasn't aware of that. I'll have to look into IE's and other browser's behavior fist. When you say every DOM manipulation, does that include those done by scripts as well? 57722 5 ian 2011-10-03 19:07:43 +0000 Yeah. The only ones that can be done that I can think of actually are scripted DOM manipulations, and DOM manipulations that are a direct result of the drag/drop operation's events' default actions. 58618 6 rniwa 2011-10-21 04:44:33 +0000 (In reply to comment #3) > It's more than that, though. Literally every DOM manipulation done to the > document between the start of the drag and drop operation and the end of it > ends up in the browser's undo transaction history, at least in IE. that is > whether it was done by script, or indeed anything else. I'm not observing this behavior. I've tried mutating DOM on dragstart, drop, etc... events but they don't appear to be included in IE's undo stack. The change I made just stays in the DOM. Could you elaboarate (perhaps a test case?) what you're observing? Or are you referring to the DOM changes made by IE itself? 58863 7 ian 2011-10-25 04:57:56 +0000 As discussed on IRC, I think the mutations I tried were done in setTimeout(). Does that help? I'm not sure we want to be duplicating this though. It may be that that should be considered a bug. 59033 8 ian 2011-10-27 00:03:36 +0000 I've removed the text in question from HTML altogether. Let me know if there's anything you need changed in the HTML spec with respect to tracking DOM changes for undo when they are done from a timeout during a drag-and-drop, and whether there's anything I need to do to make the actual user-effected changes during a drag-and-drop (e.g. the moving of a text selection in contenteditable="") actually result in the right undo transactions. 59035 9 contributor 2011-10-27 00:07:47 +0000 Checked in as WHATWG revision r6770. Check-in comment: drop the note about the implications of drag-and-drop on undo http://html5.org/tools/web-apps-tracker?from=6769&to=6770 59815 10 rniwa 2011-11-10 04:09:49 +0000 (In reply to comment #7) > As discussed on IRC, I think the mutations I tried were done in setTimeout(). > Does that help? Yeah, it appears that MSIE restores any DOM mutations done after dragstart event and immediately before drop event. > I'm not sure we want to be duplicating this though. It may be that that should > be considered a bug. It's possible that some contents depend on this behavior so I'll probably bring it up on public-webapps or contact someone at Microsoft before finalizing it. 59816 11 1043 rniwa 2011-11-10 04:10:16 +0000 Created attachment 1043 test case Here's some test case I used. 69950 12 contributor 2012-07-13 18:33:02 +0000 This bug was cloned to create bug 17773 as part of operation convergence. 123103 13 annevk 2015-09-05 17:54:22 +0000 Ryosuke, you stopped working on undo manager, right? Given that, and given that the red text from comment 1 appears to be gone. Can I close this? 123113 14 rniwa 2015-09-06 23:04:12 +0000 Yeah, I did when I left Google. However, I've been told that someone from Google is still interested in maintaining the spec. Try contacting slightlyoff? 125623 15 annevk 2016-03-25 05:08:05 +0000 I asked Alex, he said this stopped being developed when you left. 1043 2011-11-10 04:10:16 +0000 2011-11-10 04:10:16 +0000 test case drag-test.html text/html 462 rniwa PCFET0NUWVBFIGh0bWw+DQo8aHRtbD4NCjxib2R5Pg0KPGRpdiBpZD0idGVzdCIgb25kcmFnc3Rh cnQ9IihmdW5jdGlvbigpe2RvY3VtZW50LmdldEVsZW1lbnRCeUlkKCdzb21lMicpLnRleHRDb250 ZW50ID0gJ3ZhbHVlMic7DQpkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgnc29tZTMnKS50ZXh0Q29u dGVudCA9ICd2YWx1ZTInO30pKCk7Ig0Kb25kcm9wPSIoZnVuY3Rpb24oKXtkb2N1bWVudC5nZXRF bGVtZW50QnlJZCgnc29tZTNiJykudGV4dENvbnRlbnQgPSAndmFsdWUyJzt9KSgpOyINCmNvbnRl bnRlZGl0YWJsZT5oZWxsbyB3b3JsZCA8YiBpZD0ic29tZSI+ZHJhZzwvYj4gbWUNCjxwIGlkPSJz b21lMiI+dmFsdWUxPC9wPjxwIGlkPSJzb21lMmIiPnZhbHVlMTwvcD4NCjwvZGl2Pg0KPHAgaWQ9 InNvbWUzIj52YWx1ZTE8L3A+PHAgaWQ9InNvbWUzYiI+dmFsdWUxPC9wPg0KPC9ib2R5Pg0KPC9o dG1sPg0K