Status

()

defect
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: bholley, Assigned: bholley)

Tracking

unspecified
mozilla23
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Assignee)

Description

6 years ago
Once XBL runs in a compartment and the associated machinery no longer runs behind a pref, we can kill the dynamic check in SOWs.
(Assignee)

Comment 2

6 years ago
Now that XBL scopes are here to stay (no more pref), we can remove all the
machinery that makes SOWs dynamic. We still need SOWs until bug 825392 is
fixed, but they can now be totally opaque.

One side effect of this patch is that, due to our usage of Opaque, we now
allow CALL on SOWs. But this shouldn't be a problem, because SOWs are used
for anonymous elements which are not callable (and we probably wouldn't mind
it even if they were).
Attachment #745215 - Flags: review?(gkrizsanits)
(Assignee)

Comment 3

6 years ago
We have to do this if we want to proceed with eliminating SOWs entirely. Given
the other restrictions around remote XUL, I don't think this is a problem.

With this, the test suite should be green.
Attachment #745429 - Flags: review?(bzbarsky)
Comment on attachment 745429 [details] [diff] [review]
Disable SOWs for remote XUL domains. v1

So nsINode::WrapObject will take the return value of WrapSOWObject() and treat it as a SOW.  Should it be comparing the return value to the value it already had and skipping the "set is as SOW" steop if this new early return is taken?

r=me with maybe some comments in WrapObject about the issue.
Attachment #745429 - Flags: review?(bzbarsky) → review+
Attachment #745215 - Flags: review?(gkrizsanits) → review+
(Assignee)

Comment 5

6 years ago
You're right Boris, this approach is problematic, because the callers of WrapSOW
object really do expect to get a wrapper, so the logic here needs to be moved
one level up.

Note that we shouldn't need any special handling in the wrapper reparenting
paths, because those all depend on whether a SOW was there already. So that
would only be an issue if it were possible to adoptNode from a non-remote-XUL
domain into a remote-XUL domain, which thankfully can't happen.
Attachment #745429 - Attachment is obsolete: true
Attachment #745710 - Flags: review?(bzbarsky)
(Assignee)

Comment 7

6 years ago
(In reply to Bobby Holley (:bholley) from comment #6)
> https://tbpl.mozilla.org/?tree=Try&rev=07b8115419f3

Green.
Comment on attachment 745710 [details] [diff] [review]
Disable SOWs for remote XUL domains. v2

>+    // If we're now allowing XBL scopes, that means we're running as a remote

s/now/not/

Looks good, thanks!

r=me
Attachment #745710 - Flags: review?(bzbarsky) → review+
https://hg.mozilla.org/mozilla-central/rev/f6f8e02a9ab0
https://hg.mozilla.org/mozilla-central/rev/a28afac94104
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla23
You need to log in before you can comment on or make changes to this bug.