Failure to serialize array returned by content in frame script

RESOLVED FIXED

Status

()

Core
XPConnect
RESOLVED FIXED
7 years ago
6 years ago

People

(Reporter: cjones, Assigned: mrbkap)

Tracking

unspecified
Points:
---

Firefox Tracking Flags

(firefox6 fixed, fennec6+)

Details

(Whiteboard: fixed-in-tracemonkey)

Attachments

(2 attachments, 1 obsolete attachment)

In a setup that looks approximately like,

  <xul window>
    <browser src="http://foo.com">
      (frame script X loaded by browser)

if script X calls a function from foo.com's |window|, and that function returns an array, then the array is JSON'd by script X, the JSONinification seems to be failing: when un-JSON'd, what was formerly an array comes out as non-array object.  Sorry for the lack of detail, but the only testcase I have right now is a heavily modified reftest framework, which is not very small.  I'll cook up a small testcase.

hg bisect says what's "at fault" is

The first bad revision is:
changeset:   58746:0641328503d8
user:        Blake Kaplan <mrbkap@gmail.com>
date:        Fri Dec 03 19:00:23 2010 -0800
summary:     Bug 614757 - Properly deep wrap via call/construct. r=gal

It might be that there's a better way to do what my code is doing, but the code did work previously.
Created attachment 496694 [details] [diff] [review]
Test that triggers mismatched-compartments assertion (not the bug you're looking for)

Figured I'd attach this so I don't lose it.  Will follow up to see if this is a separate bug.
Created attachment 496735 [details] [diff] [review]
Small-ish test case

Run

  TEST_PATH="js/src/xpconnect/tests/chrome" make -C $objdir mochitest-chrome

and you should see

42 ERROR TEST-UNEXPECTED-FAIL | chrome://mochitests/content/chrome/js/src/xpconnect/tests/chrome/test_bug618176.xul | array was serialized and deserialized - got undefined, expected 3

As noted in a comment in the test, if |[ 1, 2, 3 ]| is serialized instead of the content array, the test passes.
Attachment #496694 - Attachment is obsolete: true
Nom'ing for blocking-fennec because this behavior change might affect extensions.  (I'm surprised it hasn't bitten the fennec frontend!)
tracking-fennec: --- → ?

Updated

7 years ago
tracking-fennec: ? → 2.0+
No longer blocks: 615386
tracking-fennec: 2.0+ → 2.0next+

Updated

6 years ago
Assignee: nobody → gbrown
(Assignee)

Comment 4

6 years ago
Created attachment 525536 [details] [diff] [review]
Proposed fix

With a CrossOriginWrapper around an array we actually have CrossOriginWrapper(WaiveXRayWrapper(array)). We need to strip off both layers to see the true type of the wrapped object.
Assignee: gbrown → mrbkap
Status: NEW → ASSIGNED
Attachment #525536 - Flags: review?(gal)

Updated

6 years ago
Attachment #525536 - Flags: review?(gal) → review+

Comment 5

6 years ago
We should have a proper channel for this (an internal proxy method that tells you whether its an array)
(Assignee)

Comment 6

6 years ago
http://hg.mozilla.org/tracemonkey/rev/907c8fc9370b
Whiteboard: fixed-in-tracemonkey
tracking-fennec: 2.0next+ → 6+
(Assignee)

Comment 7

6 years ago
http://hg.mozilla.org/mozilla-central/rev/907c8fc9370b
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
status-firefox6: --- → fixed
You need to log in before you can comment on or make changes to this bug.