Tidy up the install event specification

[mgiuca]

I'm looking at implementing the install event in Chrome and there are a few things that are implied but not explicit in the Installation Events section.

1. It doesn't explicitly state the type/interface of the event object (which I assume is Event because there's no special metadata).
2. The Installation algorithm states when to fire the "install" event at the window object, but this isn't mentioned or linked up in the Installation Events section. It isn't explicit that there's a connection between the "install" event being fired in Section 2.4 and the oninstall IDL attribute. (This section doesn't ever mention the circumstances under which the event is dispatched, despite it being mentioned previously.)

Bascially, you can figure out what's going on from reading the example, but I feel it isn't concrete in the spec, the way events in Service Workers spec are defined.

Also, I'm not really familiar with the way events are normally added to the Window object (please correct me if ignorant), but I didn't think defining a mixin interface was necessary. In WebIDL, can't you just write:

partial interface Window {
  attribute EventHandler oninstall;
}

to extend the Window object without it having to implement a new interface?

[marcoscaceres]

It doesn't explicitly state the type/interface of the event object (which I assume is Event because there's no special metadata).

Correct. Will clarify.

2... Bascially, you can figure out what's going on from reading the example, but I feel it isn't concrete in the spec, the way events in Service Workers spec are defined.

Will clarify based on how SW does it.

to extend the Window object without it having to implement a new interface?

Having it as a mixin gives us the ability to potentially mixit in elsewhere - however, I don't have a strong opinion. I currently have it implemented as a mixin in Gecko.

@domenic, does it make a big difference if it's defined as new Interface or would it be better to just use a partial interface?

[domenic]

It doesn't make a difference, but I agree that a partial interface is probably more what people expect for this sort of scenario. I guess my rule of thumb would be to not use a mixin until there's actually multiple places to mix it in?

[marcoscaceres]

I guess my rule of thumb would be to not use a mixin until there's actually multiple places to mix it in?

Yeah, that seems fair enough. Will change it.

[marcoscaceres]

Updated Gecko implementation to match: https://bugzilla.mozilla.org/show_bug.cgi?id=1280777

[mgiuca]

Thanks, that was quick. I'm not quite sure on if you went with the mixin, whether the name AppInstallEventHandlers would actually be visible to websites, or whether it would just be a spec detail. If the latter, then it shouldn't matter whether it's spec'd as a mixin or a partial interface (so then I think a partial interface would be cleaner in the spec, implementation doesn't need to change).

[RobDolinMS]

Tagging @seksenov and @Gr8Gatsby so they're aware of this

[mgiuca]

@RByers asked on #475 about cancelable and bubbles properties of the install event.

[RByers]

The interface name should be only a spec detail because there is no constructor or interface object. There have been mixins defined for other events with no actual web-exposed implications AFAIk.

[marcoscaceres]

@RByers asked on #475 about cancelable and bubbles properties of the install event.

It just assumes the defaults as per the DOM spec (i.e., both false): https://dom.spec.whatwg.org/#concept-event-fire

[marcoscaceres]

I'm not quite sure on if you went with the mixin, whether the name AppInstallEventHandlers would actually be visible to websites, or whether it would just be a spec detail.

I used the partial interface.

It would not have been exposed regardless, because it's a [NoInterfaceObject].

partial interface would be cleaner in the spec

Yep. It's what we have now :) Spec now updated we've merged the other PR.