- From: <bugzilla@jessica.w3.org>
- Date: Fri, 13 Jul 2012 18:32:58 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17773
Summary: Drag-and-drop / undo manager interaction
Product: HTML WG
Version: unspecified
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: HTML5 spec
AssignedTo: dave.null@w3.org
ReportedBy: contributor@whatwg.org
QAContact: public-html-bugzilla@w3.org
CC: ian@hixie.ch, mike@w3.org,
public-html-wg-issue-tracking@w3.org,
public-html@w3.org, rniwa@webkit.org
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
test case
Here's some test case I used.
================================================================================
--
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Friday, 13 July 2012 18:33:00 UTC