Compartment mismatch accessing during COW prototype remapping

RESOLVED FIXED in Firefox 15



5 years ago
5 years ago


(Reporter: bholley, Assigned: bholley)




Firefox Tracking Flags

(firefox15+ fixed, firefox16+ fixed, firefox17 fixed, firefox-esr10- fixed)


(Whiteboard: [qa?])


(1 attachment)

From bug 760109 comment 44.
Created attachment 646829 [details] [diff] [review]
Bug 778409 - Enter the compartment of unwrappedProto rather than obj in Rewrap. v1

This can happen if chrome sets its proto to a content object from a different scope
than the one doing the wrapping. In this case, the prototype chain looks like this:

chromeobj => CCW(examplecom_obj) => CCW(examplecom_scope.Object.prototype)

When wrapping chromeobj for exampleorg_scope, things will look like this:

COW(chromeobj) => CCW(examplecom_obj) => CCW(examplecom_scope.Object.prototype)

Note that we don't remap the proto of CCW(examplecom_scope) to
exampleorg_scope.Object.prototype, because the proto remapping only happens when
the object we're wrapping is chrome. There's no reason it has to be this way, but
even if we changed it we still wouldn't get the nice remapped lookup behavior to
exampleorg_scope.Object.prototype, because the proxy handler for CCW(examplecom_obj)
isn't a ChromeObjectWrapper, and thus doesn't know how to to the prototype bouncing

Anyway, I suspect this case isn't worth worrying about as long as we don't crash.
Attachment #646829 - Flags: review?(mrbkap)
Duplicate of this bug: 778742
Duplicate of this bug: 778748
Duplicate of this bug: 778639
Comment on attachment 646829 [details] [diff] [review]
Bug 778409 - Enter the compartment of unwrappedProto rather than obj in Rewrap. v1

Review of attachment 646829 [details] [diff] [review]:

Looks good.
Attachment #646829 - Flags: review+
Pushed to m-i:


5 years ago
Attachment #646829 - Flags: review?(mrbkap) → review+

Comment 7

5 years ago
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
Duplicate of this bug: 685965
Keywords: regression
tracking 15 and 16 because bug 760109 is tracking those branches.
status-firefox17: --- → fixed
tracking-firefox15: --- → +
tracking-firefox16: --- → +
tracking-firefox-esr10: --- → 15+
This got landed to branches over with the patches in bug 760109.
status-firefox15: --- → fixed
status-firefox16: --- → fixed
Removing the ESR tracking here since this is being tracked for ESR10 over on bug 760109.
tracking-firefox-esr10: 15+ → -
Pushed to esr10:
status-firefox-esr10: --- → fixed

Comment 13

5 years ago
Is there some way QA can verify this bug?
Whiteboard: [qa?]
You need to log in before you can comment on or make changes to this bug.