From bug 760109 comment 44.

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 correctly. Anyway, I suspect this case isn't worth worrying about as long as we don't crash.

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.

Pushed to m-i: http://hg.mozilla.org/integration/mozilla-inbound/rev/a0fbc2a467eb

tracking 15 and 16 because bug 760109 is tracking those branches.

This got landed to branches over with the patches in bug 760109.

Removing the ESR tracking here since this is being tracked for ESR10 over on bug 760109.

Pushed to esr10: https://hg.mozilla.org/releases/mozilla-esr10/rev/e23789e6cea4

Is there some way QA can verify this bug?