27030 2014-10-13 13:31:23 +0000 ArrayBuffer and friends are now covered by IDL. 2019-03-29 20:29:43 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other All RESOLVED LATER P3 normal Unsorted 28798 27031 1 contributor ian annevk bzbarsky d ian mike contributor oldest_to_newest 113022 0 contributor 2014-10-13 13:31:23 +0000 Specification: https://html.spec.whatwg.org/ Multipage: https://html.spec.whatwg.org/multipage/#arraybuffer Complete: https://html.spec.whatwg.org/#arraybuffer Referrer: Comment: ArrayBuffer and friends are now covered by IDL. Posted from: 46.127.136.57 User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.13 Safari/537.36 115164 1 ian 2014-11-19 22:49:58 +0000 This is just a change to the "Dependencies" section right? 115209 2 annevk 2014-11-20 11:38:15 +0000 The other usage can be cleaned up as well. E.g. IDL defines algorithms for extracting bytes, defines BufferSource as typedef for ArrayBuffer/ArrayBufferView. 115259 3 ian 2014-11-20 20:45:59 +0000 I don't understand what exactly it is you want updated. I don't extract bytes anywhere, do I? Do you see anything where BufferSource would be useful other than removing one line of IDL from the WebSocket IDL? 115270 4 annevk 2014-11-21 08:16:25 +0000 WebSocket, yes, it also extracts the data. Structured cloning extracts the data. But yes, also "Dependencies". 115335 5 ian 2014-11-21 23:51:27 +0000 I guess I don't understand what you mean by "extracts the data" then? Can you elaborate on what you'd like changed? 115352 6 annevk 2014-11-22 10:10:40 +0000 For WebSocket: "The data to be sent is the data stored in the buffer described by the ArrayBuffer object." "The data to be sent is the data stored in the section of the buffer described by the ArrayBuffer object that data references." This should instead reference the copy algorithm from IDL (and use BufferSource). In particular I think the second sentence is currently wrong as a view can represent a segment of an underlying buffer. For Transferable objects: "ArrayBuffer [ECMA262]" That is defined in IDL now. (You also cannot reference JavaScript objects and then use them in a typedef.) The neuter bit here is out of sync as well, but there's a separate bug for that. For internal structured cloning algorithm: this could reference the copy algorithm for ArrayBuffer, but it might not be worth it to change that. For dependencies: The ArrayBufferView typedef is no longer needed. ArrayBuffer no longer needs to be defined as part of JavaScript. 115417 7 ian 2014-11-24 18:56:15 +0000 (In reply to Anne from comment #6) > For WebSocket: > > "The data to be sent is the data stored in the buffer described by the > ArrayBuffer object." > > "The data to be sent is the data stored in the section of the buffer > described by the ArrayBuffer object that data references." > > This should instead reference the copy algorithm from IDL (and use > BufferSource). I don't understand why. The algorithms just do type checking, and otherwise basically do exactly what the HTML spec says. Why isn't the type-checking done when the arguments are passed? > In particular I think the second sentence is currently wrong > as a view can represent a segment of an underlying buffer. The second sentence handles that find as far as I can tell. The other changes are those mentioned in comment 1 (and the things that implicitly result from those changes). 115447 8 annevk 2014-11-25 10:10:34 +0000 (In reply to Ian 'Hixie' Hickson from comment #7) > I don't understand why. If only for the simple fact that then nobody thinks this situation is somehow special. > The second sentence handles that find as far as I can tell. I don't really see how. You introduce terms such as "buffer" that have no meaning in either IDL or JavaScript. You say the buffer is described by the ArrayBuffer object, while the ArrayBuffer object can represent a larger buffer than the view represents. It's not at all clear to me. 115550 9 ian 2014-11-26 19:39:12 +0000 (In reply to Anne from comment #8) > If only for the simple fact that then nobody thinks this situation is > somehow special. I'm not arguing that HTML should be different, I'm saying nobody should have to do this. Why aren't we just checking this in the argument checking step, instead of requiring that all users of ArrayBuffer have this boilerplate? > > The second sentence handles that find as far as I can tell. > > I don't really see how. You introduce terms such as "buffer" that have no > meaning in either IDL or JavaScript. You say the buffer is described by the > ArrayBuffer object, while the ArrayBuffer object can represent a larger > buffer than the view represents. It's not at all clear to me. It references "the section of the buffer" not just "the buffer". This is just English, the word "buffer" is a well-known computer science term that seems to map fine to the WebIDL/JS terminology. I mean, it's basically the same as what the WebIDL spec says — it just does a bunch of type checking which I think should happen at argument checking time, and then just returns "a reference to or copy of (as required) the length bytes in data starting at byte offset offset" which is no more defined than what HTML says, when you get right down to it. 115557 10 ian 2014-11-26 20:04:07 +0000 *** Bug 26968 has been marked as a duplicate of this bug. *** 115597 11 annevk 2014-11-27 08:07:19 +0000 I think IDL does not do it at the point of argument checking because then it would require an upfront decision about whether to get the bytes by-copy or by-reference (when we introduced this we were not quite sure what would be a better default). If we can find a decent way to do that, that might be better model though. I recommend filing a bug on IDL. 115644 12 ian 2014-11-28 04:27:16 +0000 Don't all APIs know whether they're copying or referencing the data? 115650 13 annevk 2014-11-28 07:55:06 +0000 I think they do, yes. 115676 14 ian 2014-11-29 00:25:03 +0000 If the APIs know what they're doing, then I think the IDL should just do the checking up-front. That way the behaviour is much more consistent. 115686 15 annevk 2014-11-29 15:35:50 +0000 As I said, I recommend filing a bug on IDL. 117234 16 ian 2015-01-15 20:14:45 +0000 bz, would it make sense to update IDL for this? 117238 17 bzbarsky 2015-01-15 20:43:21 +0000 Not all consumers know whether they're copying or referencing. For example, a WebGL implementation might do either one depending on how it's actually implemented. That said, what exact checking would you expect to be done up front if an API _did_ know whether it's copying or referencing? 117253 18 ian 2015-01-15 23:29:37 +0000 Well the behaviour can't depend on how it's implemented, that would be visibly non-interoperable. The question is just whether any specs sometimes do one and sometimes do the other, as opposed to any method always doing one or the other. In any case it looks like the behaviour now is just always the same. I'm not sure if I misread it before or if it changed. The checking I'm referring to is the checking in the algorithm introduced as "When getting a reference to or getting a copy of the bytes held by a buffer source that is an ECMAScript ArrayBuffer, DataView or typed array object, these steps must be followed:" in the Web IDL spec. I argue that this should just move to argument checking step of method invocation, so that we don't get weirdness about exactly when these checks happen. 117265 19 bzbarsky 2015-01-16 02:51:51 +0000 Ah, I see. So just to make sure we're on the same page, this algorithm does the following checks: Step 5: Check whether O has a [[ViewedArrayBuffer]] internal slot. If it does, O is a typed array or data view; if it does not, O is a ArrayBuffer. This check is just needed to decide where exactly the data lives. Step 5.2: In the "[[ViewedArrayBuffer]] exists" case, check for the value in the slot being undefined. This is only possible if the typed array is in the middle of being constructed and hasn't been initialized yet. And that state is going to go away with the edits Allen is making to the ES6 constructor protocol right now. So at that point, this check will go away, I'd think. Step 7: Checks for a detached buffer. This presumes that extracting data from a detached buffer should be a TypeError as opposed to silently getting an empty buffer. This check cannot be performed during argument conversion, because conversion of a later argument can detach the buffer, as can anything else which allows JS to run. Therefore, this check MUST be performed immediately before the data is extracted. Furthermore, specifications and implementations that reference the data instead of copying it must ensure that no script runs between the "getting a reference to" algorithm running and the last use of the data. Is there some other check I'm missing that's at issue here? 117266 20 bzbarsky 2015-01-16 03:00:27 +0000 Ah, and right after that comment I got the mail about http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#january_15_2015_draft_rev_31 now existing and all the checks for the value in [[ViewedArrayBuffer]] being undefined are gone in there. 117291 21 ian 2015-01-17 18:10:10 +0000 At this point, the algorithm doesn't seem necessary any more. We should just define what bytes these objects represent, and then the calling specs would be much more readable. IMHO. That is, instead of: ... 5. Let _data_ be the result of _getting a copy of the bytes held by a buffer source_ /foo/. If this throws an exception, then ... ... ...we'd just say: ... 5. If /foo/ is neutered, then ... 6. Let _data_ be the data represented by /foo/. ... Similarly, the "detach" algorithm seems pointlessly trivial as specced. What value does it add? We should just make the JS spec referenceable directly. 117293 22 bzbarsky 2015-01-17 20:19:25 +0000 > 6. Let _data_ be the data represented by /foo/. Then we need to define "the data represented by /foo/", right? This is not a theoretical concern; implementors and spec authors have screwed this up in the past. Which is why it's good to have one place which defines this concept that everyone else can then reference. Given such a shared definition, your proposal sounds ok to me, except there is no such thing as "neutered" anymore. It's called "detached". 117294 23 annevk 2015-01-18 08:02:40 +0000 Referencing JavaScript directly doesn't make sense, unless IDL values can sometimes be JavaScript objects. The layering is: JavaScript -> IDL -> feature spec -> IDL -> JavaScript 117412 24 bzbarsky 2015-01-21 21:03:36 +0000 IDL values can totally be JS objects, right? I mean, consider the "object" type. It's "an IDL value that represents the given JS object", but presumably that means that as long as you're willing to make your prose JS-specific you can unambiguously talk about the JS object represented by the "object" type IDL value. The various BufferSource types have similar behavior. 124445 25 d 2015-12-16 16:40:55 +0000 https://github.com/whatwg/html/commit/52f96c455a53763a7fe00162c067da6adb20e62c fixes the dependencies section, but the changes to use BufferSource and to be clear about copying vs. not are still to-do. 125523 26 annevk 2016-03-16 14:07:02 +0000 I thought about fixing this, but bug 28798 should really be fixed first. With that bug fixed for our cases we don't even have to worry about extracting bytes, IDL will just hand us bytes. 129676 27 d 2019-03-29 20:29:43 +0000 It seems this needs to be fixed across the specification ecosystem as part of the Web IDL work, and is not worth tracking as HTML specifically. So, I will close this and let us continue tracking work in https://www.w3.org/Bugs/Public/show_bug.cgi?id=28798 and its GitHub successor.