[whatwg] DND: proposal to expose origin

Charles Pritchard chuck at jumis.com
Sun Feb 19 16:49:59 PST 2012


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






More information about the whatwg mailing list