Closed
Bug 834707
Opened 12 years ago
Closed 12 years ago
Kill dynamic SOWs
Categories
(Core :: XPConnect, defect)
Core
XPConnect
Tracking
()
RESOLVED
FIXED
mozilla23
People
(Reporter: bholley, Assigned: bholley)
References
Details
Attachments
(2 files, 1 obsolete file)
15.49 KB,
patch
|
gkrizsanits
:
review+
|
Details | Diff | Splinter Review |
4.96 KB,
patch
|
bzbarsky
:
review+
|
Details | Diff | Splinter Review |
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 1•12 years ago
|
||
Assignee | ||
Comment 2•12 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•12 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 4•12 years ago
|
||
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+
Updated•12 years ago
|
Attachment #745215 -
Flags: review?(gkrizsanits) → review+
Assignee | ||
Comment 5•12 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 6•12 years ago
|
||
Assignee | ||
Comment 7•12 years ago
|
||
(In reply to Bobby Holley (:bholley) from comment #6)
> https://tbpl.mozilla.org/?tree=Try&rev=07b8115419f3
Green.
Comment 8•12 years ago
|
||
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+
Assignee | ||
Comment 9•12 years ago
|
||
Comment 10•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/f6f8e02a9ab0
https://hg.mozilla.org/mozilla-central/rev/a28afac94104
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla23
You need to log in
before you can comment on or make changes to this bug.
Description
•