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 23417 - Structured clone should check neutered for all types
Summary: Structured clone should check neutered for all types
Status: RESOLVED FIXED
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL:
Whiteboard:
Keywords:
Depends on: 23416
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-02 01:38 UTC by Glenn Maynard
Modified: 2013-11-22 20:19 UTC (History)
2 users (show)

See Also:


Attachments

Description Glenn Maynard 2013-10-02 01:38:39 UTC
Currently, the check to throw DataCloneError is performed in the individual types that use it.  This caused an oversight: cloning a Blob which has been neutered should throw DataCloneError, but currently doesn't per spec.

I'd suggest moving the neutered check out of the type list, and doing it near the top of http://www.whatwg.org/specs/web-apps/current-work/#internal-structured-cloning-algorithm.  Otherwise, the neutered check needs to be added to the Blob and File cases.
Comment 1 Ian 'Hixie' Hickson 2013-10-04 21:50:41 UTC
This doesn't make sense. Only Transferable objects can be neutered, and, with the exception of ArrayBuffer which can be both transfered and copied, Transferable objects can't be copied. There'd be no other type to apply this to.

Separate from this, Blob and File objects can be "neutered through the close method". This has nothing to do with Transferable objects being neutered. If a Blob that has been "neutered through the close method" can't be cloned, I'm happy to add something that says as much. Is that the case?
Comment 2 Glenn Maynard 2013-10-04 21:57:03 UTC
(I'll defer replying to this one, since it'll probably mirror the discussion in #23416.)
Comment 3 Ian 'Hixie' Hickson 2013-11-13 22:09:00 UTC
Bug 23416 is resolved now; what remains here? Should disabled Blobs not be cloneable? Or should they just be cloned in the disabled state? Do I need to say anything explicitly?
Comment 4 Glenn Maynard 2013-11-14 15:53:28 UTC
I just think we should avoid having some dead objects throw when cloned and others not.  If cloning a dead ArrayBuffer throws, it seems like cloning a dead Blob should too.  Alternatively, not throwing at all makes sense: if you post a dead ArrayBuffer, the other side receives an equally dead object.
Comment 5 Ian 'Hixie' Hickson 2013-11-21 23:35:11 UTC
You can't make an ArrayBuffer go dead, can you? I mean, short of Transferring it, but that's a special case (the rule that applies in that case is just "you can't Transfer an object twice", not "you can't transfer a dead object").
Comment 6 Glenn Maynard 2013-11-22 01:53:13 UTC
(In reply to Ian 'Hixie' Hickson from comment #5)
> You can't make an ArrayBuffer go dead, can you? I mean, short of
> Transferring it, but that's a special case (the rule that applies in that
> case is just "you can't Transfer an object twice", not "you can't transfer a
> dead object").

You can't clone (even without transfer) an ArrayBuffer that's been transferred.  If that's going to be the general rule--"you can't clone an object that's been transferred"--then I think you shouldn't be able to clone a Blob that's been closed, either.

We have objects that can become inaccessible due to being transferred (ArrayBuffer) and objects that can become inaccessible due to being explicitly killed (Blob.close).  I think it's inevitable that we'll have objects that are both, and it seems sucky to have two different ways a single object might be dead, with different effects.  (If ArrayBuffer gets a .close() method like Blob, it would become one of those.)

So, either 1: yes, cloning a disabled Blob should throw, or 2: ArrayBuffer should no longer throw if cloned while neutered.

I lean towards #2.  It's simpler, and throwing could be annoying.  If you have a big, complex structure you want to hand off, and part of the structure is dead ArrayBuffers or Blobs, it'd force the developer to remove the dead objects, even if they have no other need to remove them.  I think throwing an exception when you try to actually access a dead object is enough, and structured clone (and probably transfer, too) should just give the receiver an equally dead object.
Comment 7 Ian 'Hixie' Hickson 2013-11-22 18:05:46 UTC
> You can't clone (even without transfer) an ArrayBuffer that's been
> transferred.

Hm, that's an interesting point.
Comment 8 Ian 'Hixie' Hickson 2013-11-22 20:18:53 UTC
Ok, I've made dead blobs throw as well.
Comment 9 contributor 2013-11-22 20:19:12 UTC
Checked in as WHATWG revision r8310.
Check-in comment: Prevent dead Blobs and Files from being cloned
http://html5.org/tools/web-apps-tracker?from=8309&to=8310