Re: Proposal to allow Transferables to be used in initMessageEvent
On Sat, 13 Aug 2011, Anne van Kesteren wrote: > > On Tue, 09 Aug 2011 19:20:58 +0200, Luke Zarko wrote: > > void initMessageEvent(in DOMString typeArg, in boolean canBubbleArg, in > > boolean cancelableArg, in any dataArg, in DOMString originArg, in DOMString > > lastEventIdArg, in WindowProxy? sourceArg, in sequence > > transferablesArg); > > Can we still remove initMessageEvent in favor of event constructors? That's still my plan actually. Been busy dealing with other bugs though. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Proposal to allow Transferables to be used in initMessageEvent
On Tue, 09 Aug 2011 19:20:58 +0200, Luke Zarko wrote: void initMessageEvent(in DOMString typeArg, in boolean canBubbleArg, in boolean cancelableArg, in any dataArg, in DOMString originArg, in DOMString lastEventIdArg, in WindowProxy? sourceArg, in sequence transferablesArg); Can we still remove initMessageEvent in favor of event constructors? -- Anne van Kesteren http://annevankesteren.nl/
Re: Proposal to allow Transferables to be used in initMessageEvent
On Tue, 9 Aug 2011, Luke Zarko wrote: > > I came across this while implementing support for the new > Transferable[1] interface for Chromium. initMessageEvent is defined[2] > as: > > void initMessageEvent(in DOMString typeArg, in boolean canBubbleArg, > in boolean cancelableArg, in any dataArg, in DOMString originArg, in > DOMString lastEventIdArg, in WindowProxy? sourceArg, in > sequence portsArg); > > However, postMessage is usually defined to take a sequence > [3]: > > void postMessage(in any message, in optional sequence > transfer); > > I suggest changing initMessageEvent to permit arbitrary Transferables: While it is possible for postMessage()'s second argument to take non-port Transferables (in particular ArrayBuffers), it's not possible for the generated event to contain those objects in the event.ports array, so there's no reason for the constructor to support that. > Without this change, it is not possible for a JavaScript author to > directly construct a MessageEvent with a dataArg that contains > Transferable objects (other than MessagePorts). Why not? The dataArg has type "any". -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Proposal to allow Transferables to be used in initMessageEvent
I came across this while implementing support for the new Transferable[1] interface for Chromium. initMessageEvent is defined[2] as: void initMessageEvent(in DOMString typeArg, in boolean canBubbleArg, in boolean cancelableArg, in any dataArg, in DOMString originArg, in DOMString lastEventIdArg, in WindowProxy? sourceArg, in sequence portsArg); However, postMessage is usually defined to take a sequence [3]: void postMessage(in any message, in optional sequence transfer); I suggest changing initMessageEvent to permit arbitrary Transferables: void initMessageEvent(in DOMString typeArg, in boolean canBubbleArg, in boolean cancelableArg, in any dataArg, in DOMString originArg, in DOMString lastEventIdArg, in WindowProxy? sourceArg, in sequence transferablesArg); Without this change, it is not possible for a JavaScript author to directly construct a MessageEvent with a dataArg that contains Transferable objects (other than MessagePorts). This does not imply that the ports property of MessageEvent should change. It should behave just like the ports array for MessageEvents generated by postMessage: the ports array contains all MessagePorts sent in the transfer list in the same relative order. Please let me know what you think! Luke [1] http://www.whatwg.org/specs/web-apps/current-work/complete/common-dom-interfaces.html#transferable-objects [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#event-definitions-1 [3] http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#message-ports
