DataCloneError is not helpful

NEW
Unassigned

Status

()

Core
JavaScript Engine
5 years ago
3 years ago

People

(Reporter: Yoric, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

"DataCloneError: The object could not be cloned." is not a really helpful message. What part of my object could not be cloned? Or is it the transferable list that is somehow wrong?

Several times, I have found myself spending literally hours trying to find out why my object is not clonable. I would really like more helpful messages.
This would require some JS side assistance.
Assignee: nobody → general
Component: DOM: Workers → JavaScript Engine
(Assignee)

Updated

4 years ago
Assignee: general → nobody
Created attachment 8632598 [details] [diff] [review]
Bad idea printfs when structured cloning runs out of ideas, v1

Here's a horrible patch I created.  If you do something like this on the main thread:

  w.postMessage({ f: function() { console.log('I want RPC!'); } })

You get this lovely printf to stdout:

  MT DataCloneError coming up on: function () { console.log('I want RPC!'); }

And if you do something like this to get yourself a fancy worker doing the same thing...

  blobby = new Blob(["postMessage({ f: function() { console.log('I want MTV!'); } })"], { type: 'application/javascript' })
  z = new Worker(URL.createObjectURL(blobby))

You get this equally lovely printf to stdout:

  WT DataCloneError coming up on: function () { console.log('I want MTV!'); }


And if you do something like this:

  sketchyFunc = function() { console.log('harmless'); };
  sketchyFunc.toString = function() { console.log('moohoohahaha'); return 'sucker!'; };

You get "moohoohahaha" in your console plus:

  MT DataCloneError coming up on: sucker!

(In case it's not clear, besides the whole printf thing, JS gets invoked on the stack with structured cloning going on, which seems like a horrible idea.  A less awful patch would just want XPConnect and JS's built-in toString thing going on.  I'm sure there's a way to do that.)


Also, this patch doesn't do anything with the many, many other sources of DataCloneErrors.  (https://dxr.mozilla.org/mozilla-central/search?q=DATA_CLONE_ERR)
Also, note that this specific patch only touches DOM code.  I presume the "JS side assistance" khuey is referencing has to do with getting structured cloning to maintain some type of path traversal information and/or having the error type carry a string payload?  (Maybe also the XPConnect classes?  There seem to be classes involved instead of just bare integer NSRESULTs these days, so maybe things are less hopeless than they used to be when it comes to errors.)
Right, it means that we don't know where the thing we're failing to clone is in relation to the root.  Also note that it's possible for cloning to fail for reasons other than just "unrecognized type" (e.g. you can't clone a Function) and Gecko will not get called about those.
You need to log in before you can comment on or make changes to this bug.