This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 14337 - Drag-and-drop / undo manager interaction
Summary: Drag-and-drop / undo manager interaction
Status: RESOLVED WONTFIX
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ryosuke Niwa
QA Contact: contributor
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-30 00:34 UTC by Ian 'Hixie' Hickson
Modified: 2016-03-25 05:08 UTC (History)
4 users (show)

See Also:


Attachments
test case (462 bytes, text/html)
2011-11-10 04:10 UTC, Ryosuke Niwa
Details

Description Ian 'Hixie' Hickson 2011-09-30 00:34:04 UTC

    
Comment 1 Ian 'Hixie' Hickson 2011-09-30 00:35:45 UTC
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?
Comment 2 Ryosuke Niwa 2011-09-30 21:04:59 UTC
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.
Comment 3 Ian 'Hixie' Hickson 2011-10-02 16:39:18 UTC
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.
Comment 4 Ryosuke Niwa 2011-10-03 19:02:37 UTC
(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?
Comment 5 Ian 'Hixie' Hickson 2011-10-03 19:07:43 UTC
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.
Comment 6 Ryosuke Niwa 2011-10-21 04:44:33 UTC
(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?
Comment 7 Ian 'Hixie' Hickson 2011-10-25 04:57:56 UTC
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.
Comment 8 Ian 'Hixie' Hickson 2011-10-27 00:03:36 UTC
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.
Comment 9 contributor 2011-10-27 00:07:47 UTC
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
Comment 10 Ryosuke Niwa 2011-11-10 04:09:49 UTC
(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.
Comment 11 Ryosuke Niwa 2011-11-10 04:10:16 UTC
Created attachment 1043 [details]
test case

Here's some test case I used.
Comment 12 contributor 2012-07-13 18:33:02 UTC
This bug was cloned to create bug 17773 as part of operation convergence.
Comment 13 Anne 2015-09-05 17:54:22 UTC
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?
Comment 14 Ryosuke Niwa 2015-09-06 23:04:12 UTC
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?
Comment 15 Anne 2016-03-25 05:08:05 UTC
I asked Alex, he said this stopped being developed when you left.