Re: [heycam/webidl] Need pattern for feature detecting dictionary members (#107)

It honestly took me about 10 minutes to even understanding how [that method](https://github.com/heycam/webidl/issues/107#issuecomment-425557821) works. To clarify, I assume it works by:

1. Calling `navigator.share` with `{url: ' '}`, i.e., an invalid URL, which should according to the [`share` spec](https://wicg.github.io/web-share/#share-method) reject with a `TypeError`.
2. Injecting logic to determine whether a "`files`" attribute was accessed on the dictionary passed to `share`, before it threw a `TypeError`.

I can see quite a lot of problems with this approach:

1. It assumes that the user agent's URL parser works correctly and rejects `" "`. While that *should* be the case, it means your Web Share feature detection is dependent on an edge case of the URL parser working correctly, which is [notoriously non-compliant](https://crbug.com/660384) in all known user agents. [Note: In Chrome 69, this actually succeeds. I don't know why; we do fail more complex invalid URLs, but this one passes.]
2. It assumes that the user agent invokes getters on a dictionary when a built-in function accesses its attributes. Again, this *should* be the case (?), but you're increasing the surface area for bugs in the user agent to mess with your feature detection.
3. It assumes that the getter is invoked when the implementation merely checks for the presence of an attribute. (I don't know enough about `defineProperty` to know whether this is supposed to happen or not.) This feels implementation-dependent, depending on whether it gets the value of `files`, or merely uses something equivalent to `hasOwnProperty` to check for the existence of a "`files`" attribute.
3. It assumes that the implementation checks the presence of the "`files`" attribute *before* checking whether the `url` is valid. The [spec text](https://wicg.github.io/web-share/#share-method) says to reject if no known property is present, *before* checking the URL, but it seems brittle for a web developer to rely on the implementation doing those checks in the right order.
4. It assumes that an implementation that reads the "`files`" attribute supports file sharing. That isn't necessarily true: I can imagine, for example, that we could gather metrics on how many developers are using "`files`" in their share dictionaries (thus triggering the getter) without actually supporting file sharing.
5. It's extremely arcane. It's essentially impossible for a web developer to invent it by themself, and difficult to understand once you see it, so they just have to find it in documentation somewhere and copy+paste it, trusting that it works.

[Note: Other than the above issue where `url: ' '` is accepted, if we change to a more complex invalid case: `url: 'https://example.com:65536/'`, the above approach does work with `navigator.share` on Chrome 69 for Android.]

The above issues are specific to `share`, but they illustrate that this approach may have similar issues when applied to other APIs, or not even be possible (imagine if we hadn't invoked the URL parser, then the trick wouldn't even work).

I would rather provide an explicit API to detect whether things are supported, than the above approach which amounts to developers relying on observing "implementation details" (whether those are user-agent-specific details or just the quirks of the spec text) to find out whether it's supported. In my mind, the question is: should we go ahead and make a Web-Share-specific feature detection API, or should we scope out a general one that applies to any dictionary type?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/issues/107#issuecomment-425793690