25168 - [feature][D&D] Can't advertise pointers to data

Status: RESOLVED WONTFIX

(Core :: XUL, defect, P3)

Description

[Mike Pinkerton (not reading bugmail)]

In d&d, sometimes someone might want to advertise a pointer to a data structure 
(like a tree) as a particular internal dataflavor. While that could probably be 
done using nsISupportsPRInt32 or nsISupportsVoid primitives, there isn't a 
mechanism for getting the data out and actually giving it to the OS. Shouldn't be 
hard, it just isn't there right now.

It might not be needed to even give the data to the OS since we cache the 
transferable locally, but it might cause problems when we try to get data out of 
it and get nothing.

This bug is a placeholder for me to think some more about this.

Comment 1

[Mike Pinkerton (not reading bugmail)]

accepting for m14

Comment 2

[chuang]

Thanks, it's great to see this coming.  

Comment 3

[Mike Pinkerton (not reading bugmail)]

due to all the menu regressions i have, i won't get to this by m14. sorry!

Comment 4

[Paul MacQuiddy]

*IGNORE* - massive spam changing open XPToolkit bug's QA contact to
[e-mail]

Comment 5

[Peter Trudelle]

moving to m16

Comment 6

[Mike Pinkerton (not reading bugmail)]

can't make any promises for beta2

Comment 7

[Mike Pinkerton (not reading bugmail)]

After thinking more about this, this is potentially a very bad thing to do. Since 
it is possible to have multiple instances of the browser running, this flavor 
would be meaningless and would even _crash_ when used between multiple instances 
of the application.

There is a way on mac to specify that the drag flavor is not available to 
external applications, but I don't know about win32 or gtk where this is actually 
a problem (we won't ever run more than one instance at a time on macOS).

I'm not quite sure what to do about this. On one hand, it is nice to just be able 
to pass a pointer to a data structure around, but on the other hand it is very 
dangerous. If we can restrict these "pointer" data types to be internal to the 
app, then I'll push to get these in, but if not.....

cc'ing blizzard to see if he can tell me anything about if one can restrict the 
globalness of flavors on gtk. cc'ing rjc because he has an opinion about 
everything.

Comment 8

[Christopher Blizzard (:blizzard)]

I'm torn on this.  I think that it would make it a lot easier on us to have this
ability - just passing around a pointer.  It sure would make _my_ life a whole
lot easier, I don't know about everyone else.  At the same time though I think
that anything that we drag and drop internally we should make available to
external applications too.

In gtk there is a way to specify that a drag target is only valid within the
same application but that's on the target side, not on the source side which
doesn't really help us so I don't know if that's even an option.

Comment 9

[Robert John Churchill]

My opinion:  go the extra mile (i.e. don't advertise pointers).  [Or, if its too 
hard, go shopping...]

Hey, you asked!   :^)

Comment 10

[Mike Pinkerton (not reading bugmail)]

thinking about this more this weekend:

i'd like to just use the |nsISupportsVoid| wrapper to determine if the data is a 
pointer, but that doesn't appear to be scriptable. As a result, I think i might 
have to add a |flags| parameter to the transferable's addDataFlavor() method that 
allows clients to indicate things like "is a pointer" or "is internal flavor 
only".

Since the dragservice has the transferable cached within itself throughout the 
duration of the drag, when we get a drop of an internal flavor, i can check the  
transferable and look at the flags to determine what primitive type to create for 
the pointer data. That might be the point that I've been missing on how to 
reassign the type back to the data all along.

comments?

Comment 11

[Peter Trudelle]

No more time for this, moving to M30 and putting on helpwanted radar.

Comment 12

[Peter Trudelle]

Mass-moving all M20-M30 XPToolkit bugs to Future

Comment 13

[Mike Pinkerton (not reading bugmail)]

i'll deal with this with the great dnd rewrite.

Comment 14

[Mike Pinkerton (not reading bugmail)]

fffffffuture

Comment 15

[Jonathan]

Has this been fixed in the meantime?

Comment 16

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:enndeakin, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 17

[Neil Deakin]

I don't think this is relevant anymore. We can add such a feature if a usecase comes up.