Closed
Bug 834707
Opened 10 years ago
Closed 9 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•9 years ago
|
||
https://tbpl.mozilla.org/?tree=Try&rev=52e51405f48d
Assignee | ||
Comment 2•9 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•9 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•9 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•9 years ago
|
Attachment #745215 -
Flags: review?(gkrizsanits) → review+
Assignee | ||
Comment 5•9 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•9 years ago
|
||
https://tbpl.mozilla.org/?tree=Try&rev=07b8115419f3
Assignee | ||
Comment 7•9 years ago
|
||
(In reply to Bobby Holley (:bholley) from comment #6) > https://tbpl.mozilla.org/?tree=Try&rev=07b8115419f3 Green.
![]() |
||
Comment 8•9 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•9 years ago
|
||
remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/f6f8e02a9ab0 remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/a28afac94104
Comment 10•9 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/f6f8e02a9ab0 https://hg.mozilla.org/mozilla-central/rev/a28afac94104
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla23
You need to log in
before you can comment on or make changes to this bug.
Description
•