- From: Charles Pritchard <chuck@jumis.com>
- Date: Sun, 19 Feb 2012 16:49:59 -0800
On 2/19/2012 4:28 PM, Adam Barth wrote: > On Sun, Feb 19, 2012 at 2:28 PM, Charles Pritchard<chuck at jumis.com> wrote: >> On 2/17/12 1:35 AM, Anne van Kesteren wrote: >>> Our proposal takes its cues and algorithms from the postMessage API, and >>> allows the source site to restrict drop targets to only those origins which >>> it trusts, and allows drop targets to see which origin was the source of a >>> drag. The majority of the algorithm can be copied from postMessage, >>> including the syntax for allowed target origins. >>> >>> interface DataTransfer { >>> ... >>> readonly attribute DOMString origin; >>> void allowTargetOrigin(DOMString targetOrigin); >>> }; >> Any chance we could get D&D to pass a window object or message port so we >> could use postMessage? > The source might be in a different unit of related browsing contexts, > which might mean in a different process in a multi-process browser. > In those cases, we wouldn't want to provide a window reference. > >> window.open/iframe seems the only way to link; I've used an >> iframe+sharedworker setup before, which works pretty well. > Correct. That's by design. > If contentWindow.postMessage is off the table, how about a message port? When allowTargetOrigin / origin are setup, it'd be pretty cool to be able to have an easy drag and drop of a message port without needing the shared worker trampoline. I had to use the trampoline method for a Chrome extension recently, as they don't have Transferrable setup in their chrome.* namespace. It worked well. I'm ok with the iframe+sharedworker design, I'd just like to avoid the trampoline if and when possible. -Charles
Received on Sunday, 19 February 2012 16:49:59 UTC