On 2/19/2012 4:28 PM, Adam Barth wrote:
On Sun, Feb 19, 2012 at 2:28 PM, Charles Pritchard<[email protected]> 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
