This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 25540 - Invalid use of [EnsureUTF16]
Summary: Invalid use of [EnsureUTF16]
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: XHR (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Anne
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on: 24581
Blocks:
  Show dependency tree / graph
 
Reported: 2014-05-03 04:43 UTC by Glenn Adams
Modified: 2014-05-26 23:53 UTC (History)
4 users (show)

See Also:

Attachments

Description Glenn Adams 2014-05-03 04:43:58 UTC 
In three places, the syntax

optional [EnsureUTF16] DOMString

is used; however, this syntax is not valid according to WebIDL2 Production 58 [1]. Changing these three cases to:

[EnsureUTF16] optional DOMString

fixes these problems.

[1] http://heycam.github.io/webidl/#proddef-Argument

In one place, the syntax

optional (... or [EnsureUTF16] DOMString or ...)?

is used. Unfortunately, the only way to make this valid according to WebIDL2 is to move the extended attribute before "optional", which definitely makes this semantically awkward (if not ill formed). That is, one would have to write:

[EnsureUTF16] optional (... or DOMString or ...)?

which looks rather strange when "..." is not DOMString.
Comment 2 Glenn Adams 2014-05-20 06:14:46 UTC 
Thanks!
Comment 3 Glenn Adams 2014-05-26 02:54:54 UTC 
I see the change was made in the whatwg version, and not the downstream (w3c) version. Could you downstream this to W3C please?
Comment 4 Anne 2014-05-26 08:21:08 UTC 
Please don't reopen my bugs.
Comment 5 Jungkee Song 2014-05-26 10:10:52 UTC 
W3C version updated: https://dvcs.w3.org/hg/xhr/raw-file/tip/xhr-1/Overview.html

Thanks,
Comment 6 Glenn Adams 2014-05-26 11:29:24 UTC 
(In reply to Anne from comment #4)
> Please don't reopen my bugs.

You are confused. I reported the bug, therefore it is MY bug. You are merely the assignee. In any case, I (and any other reporter of a bug) damn well have the right to reopen a bug if it isn't satisfactorily addressed.

I appreciate your addressing this bug in the WHATWG version, but the bug was reported against the W3C edition, so it isn't fixed until addressed in the latter.

Thanks to Jungkee for following through with an update.
Comment 7 Anne 2014-05-26 12:50:03 UTC 
No it wasn't. The W3C version does not have bugs associated with it. Otherwise the bug would not have been assigned to me.
Comment 8 Glenn Adams 2014-05-26 23:53:34 UTC 
(In reply to Anne from comment #7)
> No it wasn't. The W3C version does not have bugs associated with it.
> Otherwise the bug would not have been assigned to me.

Then please explain how the product code of WebAppsWG associated with this bug is associated with a WHATWG spec. Last time I checked the WebAppsWG was a W3C WG working on W3C specs (only).