45605 - Embedding Drag + Drop support

Status: VERIFIED FIXED

(Core Graveyard :: Embedding: APIs, defect, P1)

Description

[Judson Valeski]

Embedded gecko needs to define and implement support for Drag + Drop.

Comment 1

[Mike Pinkerton (not reading bugmail)]

in theory (heh), the embedding window only needs to make sure that the native d&d 
events are funnelled into the event sink just like other native events. 
Everything else should be handled internally by gecko.

Note that xul is not required to use the drag&drop services of XPTookit, though 
DOM event handlers (in JS or C++) will need to be registered in order to process 
the events.

Comment 2

[Judson Valeski]

we'll need this after beta3.

Comment 3

[Peter Trudelle]

->Pinkerton/M0.9, cc blizzard

Comment 4

[Peter Trudelle]

please add swag to status whiteboard

Comment 5

[Judson Valeski]

an embedding app needs ability to drag a "URL" from outside our content area,
onto it and have it load the URL. an embedding app also needs the reverse. The
ability to drag a "URL" from the content area outside the content area, and drop it.

Comment 6

[Mike Pinkerton (not reading bugmail)]

this depends on if there is a xul wrapper around the embedded document, or not.
The code to handle all this is 90% there and can just be copied from navigator,
but it's all in JS. If we have to re-write it in C++, it will take longer.

Is there a place to hang event listeners at the top of the embedded document?
Where is this outer document constructed? Is it different from the non-embedded
(nscp6) case?

Comment 7

[Judson Valeski]

cc'ing adam lock who utilized a xul doc layer to handle context menu
notification. We have to decide whether or not we're going to support the xul
doc layer. Currently, we're exposing c++ versions of all notifications. Most
embedders haven't bought into XUL, therefore asking them to play w/ JS isn't
well received.

Listener registration occurs here:
http://lxr.mozilla.org/seamonkey/source/embedding/browser/webBrowser/nsIWebBrowser.idl#53

window construction is done by the embedding app (see
http://www.mozilla.org/projects/embedding/webbrowser.html#_Toc485633589 )

Adam, can you address the last question?

Comment 8

[Mike Pinkerton (not reading bugmail)]

just spoke to hyatt:

what about using XBL in the same way that we do key-bindings? That allows us to
re-use the existing navigator JS and use XBL to hookup the event handlers.

Comment 9

[Judson Valeski]

please ellaborate: "hookup event handlers" (in cpp)? If we can leverage XBL to
accomplish this, great!

Comment 10

[Mike Pinkerton (not reading bugmail)]

either hook them up (use |addEventListener()|) in c++ or, preferably, via XBL
using the same mechanism we're using to hook up the keybindings.

cc'ing hyatt, since we seem to be talking about a lot of overlap with bugs he
has for keybinding tasks.

Comment 11

[Christopher Blizzard (:blizzard)]

What you are describing here is what the gtk embedding widget does except it
does it with XUL.  I hang the event listeners off an otherwise empty ( except
for the content area ) XUL document.

Comment 12

[Mike Pinkerton (not reading bugmail)]

working on this now, leveraging hyatt's XBL keybinding work.

Comment 13

[Mike Pinkerton (not reading bugmail)]

cc'ing blake and alecf since they have already started work on separating the
content area's DnD JS (woohoo).

There are a couple of tasks we see:
- hooking up the XBL to hyatt's window root (2 days)
- extracting the content area JS so that it no longer references browser window
elements (like the url bar) Alec suggested something like a
"contentAreaContainer" that wraps the dragObserver and can provide it with
different info depending on the context. This would be good for both embedding
and things like mail (2 days)
- changing the install of the content area JS (it can't live in the navigator
package for embedding reasons) and installing the XBL into the same place (1 day).

Did I miss anything?

Comment 14

[Mike Pinkerton (not reading bugmail)]

ok, I have most of the code written, problem is that we can't yet put <script> 
tags into XBL files, so we can't include all the nice XPApps content area DnD 
files (bug 58757).

I'll try to get the c++ part landed soon.

Comment 15

[Mike Pinkerton (not reading bugmail)]

Attachment: patch, not including new files

Comment 16

[Mike Pinkerton (not reading bugmail)]

Attachment: new files in mozilla/layout/xbl/src (zip file)

Comment 17

[Mike Pinkerton (not reading bugmail)]

Attachment: mozilla/layout/xbl/builtin which holds the bindings (zip)

Comment 18

[Mike Pinkerton (not reading bugmail)]

hyatt, can you a=? who would be qualified to do an r=?

Comment 19

[David Hyatt]

Ok, so here's where we stand.  From the meeting today, I got the impression we 
may not have to do the XBL drag and drop thing.  

My big concern about this is that if we don't rewrite the JavaScript code in 
C++, then we are pretty far away from making this work (given all of the nasty 
issues related to avoiding recompilation of included 
<script> and resolving trust issues with principals for the handlers and 
for included <script>).  We'd probably have to do something to enable JS to be 
compiled on the window root, and then do something to give the window root a 
principal that was trusted.  I don't really even know how to do this, and I'm 
not sure how the ownership model would work in script-land.  

While I think it's ok to check this in, we should have the window drag handler 
not be compiled (so get nsXBLWindowDragHandler out of the projects and 
makefiles) and have the hookup be disabled until we know for sure that we want 
to continue developing an XBL-based drag and drop solution.  That way we don't 
bloat the code until we're sure we're turning this on.

I don't see any code in the patch that does the transition over to the new 
htmlBindings and platformHTMLBindings files.  It looks like the new ones are 
being checked in without the old ones being removed.  Are you planning on doing 
that in a later checkin, or did you want to tackle that now?

a=hyatt.

Comment 20

[David Hyatt]

If we want to continue along this path, I'm going to need some serious help from 
brendan, since I think the nsWindowRoot would need to evolve into a full-blown 
script object with a trusted principal.

cc'ing him.

Also, you aren't really dependent on the XBL <script> bug as it turns out.  
We'll have to hack this up differently from the way normal XBL <script> tags are 
going to work.  

(This is a crack baby pseudo-XBL we're playing with, and it unfortunately 
doesn't work the same way as real XBL.)

Comment 21

[Brendan Eich [:brendan]]

There's no problem compiling a script against an object other than the one you
pass to scope the execution(s) of that script.  Also, the principal is a compile
time parameter, so you can provide a trusted one when compiling and the trust
will apply when executing.

Ask me questions in terms of the JS API if you can, I think that will move
things along fastest.

/be

Comment 22

[Mike Pinkerton (not reading bugmail)]

we're in a holding pattern here. it will be pretty easy if we can rely on a thin
xul layer (no need for script tags in xbl, and a few other things), but if we
can't, this will be a lot of work.

raising estimate to two weeks until we can get some answers.

Comment 23

[Paul Wyskoczka]

Updating QA Contact

Comment 24

[Mike Pinkerton (not reading bugmail)]

for now, i think we're going with the idea that if an embedding app wants dnd,
they can use the thin xul layer. i really don't think we want to be duplicating
all the dnd code in c++.

pushing off.

Comment 25

[Michael Dunn]

Correction: Changing QA contact for the Embed API bugs to David Epstein.

Comment 26

[Mike Pinkerton (not reading bugmail)]

ok, this is needed sooner rather than later so i'm pulling it back in.

my new plan (since the script tag just isn't gonna happen) is to migrate the
content area's JS to c++ and share it between embedding and seamonkey. I figure
i'll hang the dnd listeners off the same node where we hang the tooltip and
context menu listeners.

objections?

Comment 27

[Adam Lock]

*** Bug 79513 has been marked as a duplicate of this bug. ***

Comment 28

[Mike Pinkerton (not reading bugmail)]

Attachment: patch for seamonkey and embedding

patches seamonkey and embedding to use this new service. a new bug will cover
additional client APIs for being able to override individual stages. this gets
basic "black box" functionality in (and uses PPEmbed as a testbed).

Comment 29

[Mike Pinkerton (not reading bugmail)]

Attachment: same patch, with new files

Comment 30

[Mike Pinkerton (not reading bugmail)]

Attachment: this one actually builds

Comment 31

[Kathleen :Brade]

Comment on attachment 69542 [details] [diff] [review]
this one actually builds

r=brade

Comment 32

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 69542 [details] [diff] [review]
this one actually builds

sr=[e-mail]

Comment 33

[saari (gone)]

looks like there are a couple stray printfs in the patch that you might want to
kill.

Otherwise, cool!

Comment 34

[Mike Pinkerton (not reading bugmail)]

landed.

Comment 35

[David Epstein]

verified patch against Mozilla 0.9.8 Gecko 20020218. All OK except I noticed the
following:
* In /mozilla/embedding/browser/webBrowser/makefile.win and makefile.in, what
happened to .\nsIDragDropHandler.idl in the script pathway?
* In /mozilla/content/macbuild/contentIDL.xml, why isn't nsDragDropHandler.idl
in the paths? (<PATH> </PATH> tags)

Comment 36

[David Epstein]

Mozilla build 0.9.8 Gecko 20020222. nsIDragDropHandler.idl located in XPIDLSRCS
section of makefile.win & makefile.in in /mozilla/content/base/public. D&D works
fine in MfcEmbed's Editor window & Composer, but not to the desktop.

Comment 37

[Mike Pinkerton (not reading bugmail)]

fwiw, the not being able to drag to the desktop is 127703, just waiting on a=.

Comment 38

[David Epstein]

verified.