-
Notifications
You must be signed in to change notification settings - Fork 167
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change from getClientExtensionResults function to clientExtensionResults attribute #810
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like the [[clientExtensionsResults]]
internal slot (added in 5c8dc49) is no longer needed, correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mozilla is okay with this.
@selfissued Please review @emlun comment |
@emlun - you wrote "It looks like the [[clientExtensionsResults]] internal slot (added in 5c8dc49) is no longer needed, correct?". I suspect you're right but note that the new attribute is calledclientExtensionsResults and so that has to stay. Could you create a PR against my PR to show us what you think should change? |
There's both the attribute |
PR submitted: selfissued#4 |
Remove unnecessary internal slot [[clientExtensionsResults]]
Fixes #803 |
…ction to clientExtensionResults attribute (#810)
Sorry for the late comment, but I just noticed that per [1]: "The type of the attribute, after resolving typedefs, must not be a nullable or non-nullable version of any of the following types: ... a dictionary type" |
Oh. I think that's exactly the same rule that made us change the previous record-type attribute to an operation. So I guess we'll have to revert this, then? @equalsJeffH @selfissued |
I'm not immediately convinced that we need to revert this, although some more spec lawyering may be needed. We have the I have to get to a meeting now, but I'll try to find someone who claims to be a WebIDL expert to weigh in. |
Thanks @agl |
I'm certainly not a WebIDL expert, but IIUIC interfaces have only required members. And those can't have any default values either. If that's the case an interface probably wouldn't be a good fit for |
Adding @nadalin so he's aware of this discussion |
I've asked @jyasskin to weigh in. However, I'm not sure that the lack of optional members is a problem here. This is the browser's extension output, thus the structure only contains fields for extensions that the browser supports. It's typical for browsers that don't support something not to have certain fields (I think). For example, we suggest testing for |
To summarise what I've managed to get from emailing people who do know WebIDL:
I don't have a strong preference either way. I think the Javascript is a little cleaner if it's an interface, but not having null-valued attributes hanging around might swing it for some people. |
Having the extraneous null-valued attributes for extensions that were not requested by the RP sounds pretty sub-optimal. I hate to say it, but it seems like things will be simpler if we revert this change and go back to the function. I'll create a new PR to do so and submit it to the commenters on this thread to review. |
@selfissued Should this be closed now ? |
It's merged, which is the closed state for PRs. |
@selfissued It wasn't when I wrote the comment |
…lts attribute (w3c#810) * Change from getClientExtensionResults function to clientExtensionResults attribute * Remove unnecessary internal slot [[clientExtensionsResults]] * Make a very dense sentence slightly less dense
Fixes part of #803
Preview | Diff