This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This was was cloned from bug 14337 as part of operation convergence. Originally filed: 2011-09-30 00:34:00 +0000 Original reporter: Ian 'Hixie' Hickson <ian@hixie.ch> ================================================================================ #0 Ian 'Hixie' Hickson 2011-09-30 00:34:04 +0000 -------------------------------------------------------------------------------- HASH(0x2d9df90) ================================================================================ #1 Ian 'Hixie' Hickson 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? ================================================================================ #2 Ryosuke Niwa 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. ================================================================================ #3 Ian 'Hixie' Hickson 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. ================================================================================ #4 Ryosuke Niwa 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? ================================================================================ #5 Ian 'Hixie' Hickson 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. ================================================================================ #6 Ryosuke Niwa 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? ================================================================================ #7 Ian 'Hixie' Hickson 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. ================================================================================ #8 Ian 'Hixie' Hickson 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. ================================================================================ #9 contributor@whatwg.org 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 ================================================================================ #10 Ryosuke Niwa 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. ================================================================================ #11 Ryosuke Niwa 2011-11-10 04:10:16 +0000 -------------------------------------------------------------------------------- Created attachment 1043 [details] test case Here's some test case I used. ================================================================================
Making this a higher priority to actively seek more feedback on from implementers and webdevs.
HTML5.1 Bugzilla Bug Triage: Migrated to the HTML GitHub repo: https://github.com/w3c/html/issues/221 If this resolution is not satisfactory, please copy the relevant bug details/proposal into a new issue at the W3C HTML5 Issue tracker: https://github.com/w3c/html/issues/new where it will be re-triaged. Thanks!