Closed Bug 1613900 Opened 4 years ago Closed 4 years ago

Incorrect exception when SharedArrayBuffer cannot be serialized

Categories

(Core :: DOM: postMessage, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla75
Tracking Status
firefox75 --- fixed

People

(Reporter: annevk, Assigned: tt)

References

(Blocks 1 open bug)

Details

Attachments

(4 files)

WPT html/infrastructure/safe-passing-of-structured-data/shared-array-buffers/no-coop-coep.https.any.js (run as html/infrastructure/safe-passing-of-structured-data/shared-array-buffers/no-coop-coep.https.any.html for instance) shows that we throw a TypeError rather than a DataCloneError.

html/infrastructure/safe-passing-of-structured-data/shared-array-buffers/serialization-via-history.https.html also tests this and a number of other files in that directory do too.

Flags: needinfo?(ttung)

This is also a problem for ArrayBuffer objects as per html/infrastructure/safe-passing-of-structured-data/transfer-errors.window.html.

(In reply to Anne (:annevk) from comment #0)

WPT html/infrastructure/safe-passing-of-structured-data/shared-array-buffers/no-coop-coep.https.any.js (run as html/infrastructure/safe-passing-of-structured-data/shared-array-buffers/no-coop-coep.https.any.html for instance) shows that we throw a TypeError rather than a DataCloneError.

html/infrastructure/safe-passing-of-structured-data/shared-array-buffers/serialization-via-history.https.html also tests this and a number of other files in that directory do too.

The problem is probably because, for instance, we throw a JS exception here before we throw a DOM exception.

The question is that if we want to keep the error message for COOP and COEP headers, we might need to expose a new method in Spidermonkey to get the error message from a JSException and then throw that with DATA_CLONE_ERR.

Assignee: nobody → ttung
Status: NEW → ASSIGNED
Flags: needinfo?(ttung)
Attachment #9125448 - Attachment description: Bug 1613900 - Throw the data clone error if COOP and COEP headers are not set when there is an shared memory object; → Bug 1613900 - P1 - Throw the data clone error if COOP and COEP headers are not set when there is an shared memory object;
Attachment #9125492 - Attachment description: Bug 1613900 - P2 - Report original JS errors as warning messages before StructuredCloneCallbacksError() is implemented; → Bug 1613900 - P2 - Report original JS error message to StructuredCloneCallbacksError;

Hmm, there seem to have too many cases where we fail to serialize/deserialize a buffer and JS side doesn't call the error callback. So, I will probably remove the assertion before throwing (for ensuring error callback must propagate the message to DOM side while throwing).

Here is the try with the newest patch and puls removing the assertion to ensure mErrorMessage is not empty right before throwing:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=e21ce6f32ff4666e80923f6a9b57b351968a3e4c

Pushed by ttung@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/6f2315156e4f
P1 - Throw the data clone error if COOP and COEP headers are not set when there is an shared memory object; r=baku,sfink
https://hg.mozilla.org/integration/autoland/rev/5cfb3def4827
P2 - Report original JS error message to StructuredCloneCallbacksError; r=baku,sfink
https://hg.mozilla.org/integration/autoland/rev/819fac5523c2
P3 - ServiceWorker should treat all failures after deserializing as deserialization failures; r=dom-workers-and-storage-reviewers,perry
https://hg.mozilla.org/integration/autoland/rev/ee476560631f
P4 - Propagate the exception by setting a pending exception to the JSContext; r=baku
You need to log in before you can comment on or make changes to this bug.