Where to fire `toolactivated` and `toolcanceled` events?

[domfarolino]

The declarative API explainer introduces the toolactivated and toolcanceled events, leaves the issue of where to fire the events for future discussion. This is that discussion. The explainer initially mentions firing the events at the Window object, however in #76 (comment), @bwalderman mentions that it might make more sense to fire these events at the <form> element itself that is the declarative tool itself.

Initially this makes sense, but if we extend these events to imperative tools, the firing location becomes confusing. For declarative, they'd fire at the element itself, but for imperative they'd fire at Window which feels odd. I think if we had a dedicated Tool interface that inherited from EventTarget to represent imperative tools, then we could have a policy of always firing the events on the tool itself. But absent this, it might make sense to fire all events at the Window and call it a day.

Thoughts?

[beaufortfrancois]

How about makingnavigator.modelContext inherits from EventTarget and have both navigator.modelContext.ontoolactivated and navigator.modelContext.ontoolcanceled attribute handlers?

[bwalderman]

Having the modelContext be the event target for all tool events has a similar drawback to using the Window as the target: all of your tool events end up in one place, and you may need a big if statement to handle all the different kinds. Tool as a new interface that extends EventTarget is an interesting idea.

If modelContext.registerTool returned a Tool, that could serve as both the event target, and a means of unregistering the tool, which would address some of the concerns about unrelated javascript code unregistering tools you registered (#101)

[domfarolino]

We did consider that in discussion today. My first thought was that these events are really only useful for declarative tools, and should probably not fire for imperative tools at all. So they should definitely fire on the <form> that backs the tool /cc @mfreed7.

However, I'm not sold that these events are only useful for declarative tools, especially if we decide (as I suspect we will) that developers are responsible for managing concurrency between tools on their own, just as they are responsible for managing concurrency between JavaScript functions that get triggered by (a) other script, (b) user interactions. Designing for that world, then these events are useful for both imperative and declarative, and I vote we mostly follow the approach @beaufortfrancois mentioned above 👍

1. Make ModelContext inherit EventTarget
2. Introduce a ToolActivatedEvent (not WebMCPEvent like Chromium has)
   • Give it a toolName attribute, like Chromium has
   • Give it an element member that points to the form element, if the event represents a declarative tool
3. Introduce a ToolCanceledEvent with similar properties

This should give developers that need to manage concurrency a good global place to do so, which I suspect is important because concurrency managers might be different from tool authors.

[domfarolino]

Oops sorry, I wrote my comment before @bwalderman's, but didn't hit send or see his until way later!... will review in the context of it...

[domfarolino]

I dumped my thoughts on tool unregistration mechanisms in #130, and after I think I'm convinced that the events should fire on navigator.modelContext, since it's unlikely that tool authors are going to be the same people adding event listeners for these events.

If I'm wrong: (a) we can always reconsider where we fire the events, and (b) there should be enough information on the event I proposed above, to direct the handler to the relevant <form>, or possibly Tool object if we decide to introduce it too. Would love your thoughts.

[anssiko]

RESOLUTION: The toolactivated and toolcanceled events are fired on the ModelContext object. (issue #126)