Re: [w3c/manifest] Use WebIDL to describe the manifest data structure (#611)

I discussed with @dominickng and we have a vague plan for this.

We do want to keep defining the manifest in terms of IDL. It's just _so_ much more readable than explaining the types of all the fields by algorithms that check the types and reject if they don't match. I recall @marcoscaceres and @annevk had a few issues with this but the main issue is that we have no way of defining how much of the manifest to invalidate when there is a type error in some member (technically speaking, due to IDL, we should be invalidating the entire manifest if there is any type error, but that isn't our intention and I don't think any browser does this).

This is becoming an actual problem for us; see this [Web Share Target code review on Chromium](https://chromium-review.googlesource.com/c/chromium/src/+/1361291/2/content/renderer/manifest/manifest_parser.cc#398), where we have to unilaterally decide how much of the share target member to invalidate when an `accept` is invalid, because we don't want to invalidate the entire manifest, as the spec implicitly tells us to do.

The proposed solution is this:

1. Add to Web IDL (either directly in the Web IDL spec, or by monkey-patching from the Manifest spec) a new [ECMAScript-specific extended attribute](https://heycam.github.io/webidl/#es-extended-attributes) for types `[CatchTypeErrors]` (name can be debated, my personal preference is `[TheBuckStopsHere]` 😜). (There are a lot of these already, maybe there's already one that does this.)
2. Define ECMAScript-to-IDL conversion for `[CatchTypeErrors]` as "If during the conversion of the inner type to IDL, an exception was thrown of type TypeError, let the result be **undefined**." Essentially, this means if you put `[CatchTypeErrors]` on an optional dictionary member, any type errors inside that member will cause the member to take its default value, rather than propagating the TypeError upwards.
3. In Manifest, put `[CatchTypeErrors]` on most of the top-level members, so if any of them are invalid, they don't break the whole manifest. In the case of some more complex members, `[CatchTypeErrors]` may be put on the sub-members instead.

The behaviour I want (but haven't thought of how to define yet) is for sequence types, if you put `[CatchTypeErrors]` on the type of the sequence elements, any failing element simply drops the element from the resulting list, not putting `undefined` in the list. That's pretty key since I'd want to define `icons` as `sequence<[CatchTypeErrors] ImageResource>`, so if any icon is invalid, we drop that icon rather than dropping the whole `icons` member.

Does this sound like a reasonable approach, @marcoscaceres @annevk ?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/611#issuecomment-445611024