178582 - Make rows of DOM node tree capable of drag & drop for copying

Status: RESOLVED WONTFIX

(Other Applications :: DOM Inspector, enhancement)

Description

[Alex Vincent [:WeirdAl]]

I've been thinking a document fragment corresponds fairly closely to the 
concept of a clipboard:  something you can attach anything to.  It might be 
wise to make the clipboard accessible to DOM Inspector as a document fragment 
node.

Either that, or we can treat document fragments as clipboards themselves...

Opinions?

Comment 1

[Boris Zbarsky [:bzbarsky]]

You mean "selection" not clipboard I presume?  A selection actually maps to a
_set_ of DOM Range objects, because selections can be disconnected... There's
certainly no way to express a selection as a document fragment...

Or did you really mean clipboard?  If so, a clearer explanation, with examples,
of what you mean would be nice.

Comment 2

[Alex Vincent [:WeirdAl]]

No, I did not mean selections.  Although I can see what you might be implying, 
in that selections often end up in the clipboard.  So whatever would make it 
difficult to see a selection in DOM-I would make it equally difficult to see 
the clipboard.

Hm.  Examples...  hardest part about that is a really good example requires 
working code... plus I have to know what I'm talking about.  I'm not familiar 
with the guts of the clipboard, so maybe I'm off on a wild goose chase.  If so, 
this bug needs to die fast.

Okay, let's say we copied the document root element node to the clipboard.  
Then we selected an option from the menu bar which said, "Inspect Clipboard in 
new window".  In that case, we would be presented with a new window, where a 
document fragment node containing a complete copy of the element and its 
descendant nodes would be presented.

If it were a series of ranges, as you suggest, I would think a series of text 
nodes, in order, would be effective.  It wouldn't be the same, of course.

It gets much more difficult, now that I think about it, when you consider non-
markup items in a clipboard.  For instance, an image.  Unless it were SVG, you 
couldn't possibly represent that in DOM Inspector, and you wouldn't want to do 
that anyway.

Perhaps I should clarify my intent in this bug is not necessarily to use THE 
clipboard Mozilla provides access to via XPCOM.  That would be nice, but not 
the goal I have in mind precisely.  It would be more precise to consider 
fragment nodes as DOM-specific clipboards themselves.

If we could drag & drop or otherwise copy nodes from one DOM Inspector window 
to another, for instance, that in tandem with bug 178583 would work just fine 
for me.  The idea of fragment node as clipboard simply implies something we can 
use to create a portable, copiable document fragment for export to other 
documents.

I suppose, in a sense, this is the same as bug 178583, but creating document 
fragment nodes instead -- but also making sure we could drag them to other 
documents and having the Inspector create copies via script.

Does this help at all?  Or have I muddied the issue?

Comment 3

[Boris Zbarsky [:bzbarsky]]

So what you really want is a way to move document fragments between documents
and the clipboard (which one, on Unix?) has nothing to do with it.  Is that
about right?

Comment 4

[Alex Vincent [:WeirdAl]]

Clipboard was a misnomer.  But your summary is still off.  8)  I think the new 
summary here might clarify, if I expand 178583 to include fragments.

Comment 5

[Christopher Aillon (sabbatical, not receiving bugmail)]

Mass re-assigning bugs to [e-mail]

Comment 6

[Alex Vincent [:WeirdAl]]

Not going to happen.  Two years after I filed this bug, I have no idea what I am
talking about.  :)