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

> It assumes that the user agent invokes getters on a dictionary when a built-in function accesses its attributes.

This is a very clear requirement in the Web IDL spec, there are tests for it using several dictionary types, and I am pretty sure all browsers get this right.   There really shouldn't be failures here.

> It assumes that the getter is invoked when the implementation merely checks for the presence of an attribute.

No, it assumes that the getter is invoked as part of Web IDL argument processing.   Which, again, is a basic Web IDL spec requirement.

> It assumes that the implementation checks the presence of the "files" attribute before checking whether the url is valid.

No.   The presence check and the URL check both happen in the actual algorithm for the method, which runs after all the Web IDL argument processing is complete.  There is no assumption being made here other than correct implementation of Web IDL method calls in general.

In general, all of points 2, 3, 4 come down to "a UA could have totally broken Web IDL argument  handling", which I suspect is strictly less likely than "a  UA could have its out-of-band support claims not match its actual support".

> 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.

This one is a bit odd, actually.  Adding support for properties in dictionaries in observable ways (including calling getters) without actually supporting those properties is something that generally gets frowned on.

For purposes of the sort of telemetry you describe, I would personally implement it in terms of internal engine APIs that promised to not have side effects (e.g. not calling getters or proxy handlers).  It would undercount uses that relied on such constructs, but I would not expect web developers to typically use those in dictionaries anyway.

I do agree with your points 1 and 6, which basically come down to my two concerns above: it's hard to  make sure you call the API in a side-effect-free way and the whole thing is highly non-obvious.  The big question for some people is whether those are enough to outweigh the extra likelihood of broken out-of-band support claims.

> The above issues are specific to `share`

Only issue 1 is really specific to `share` in its specific phrasing.



-- 
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-425796026