Re: [clipboard-apis] The ClipboardEvent constructor is strange (#10)

Hi @foolip, it's correct that Gecko hasn't implemented the spec as it is now. Thanks for the implementor feedback - this part of the spec used to have createEvent() .. e.initEvent( ... ) stuff and was changed on Anne's request, so you are most likely the first implementor to read it really closely since it was rewritten. Sorry I missed it initially - GitHub sends way too much E-mail.. ;)

BTW it sounds like you're writing some tests while implementing - would be great if you could help reviewing these https://github.com/w3c/web-platform-tests/pull/1242 and give feedback - for example report bugs against the spec on stuff that's not covered by those tests.

> the spec expresses this differently

Not quite sure what "this" refers to, but maybe it doesn't matter..

> As part of "fire a clipboard event" it checks if the event is trusted and
> uses the data and dataType arguments from the constructor without
> actually storing somewhere in the interim.

Good point - nothing in the spec says explicitly that when you do ```new ClipboardEvent('paste', {dataType:'text/plain', data:'foo'})``` you'll get an event object with a clipboardData property whose items list contains a single entry.

> Also strange is that there's no way to actually run the "fire a clipboard event"
> algorithm from scripts, all of the entry points look like they're for actual copy/paste/cut actions.

That algorithm should (AFAIK) handle a scripted dispatch too though, as it makes an effort to get things like isTrusted right. What you're missing is some line somewhere saying that if dispatchEvent() is called with an event object whose constructor is ClipboardEvent, the implementation should run the "fire a clipboard event" steps?

So - if we add some text describing the construction of a clipboard event object with a DataTransfer property, and a line about dispatchEvent you'll be happy? :)

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/clipboard-apis/issues/10#issuecomment-123785462