Closed
Bug 606058
Opened 14 years ago
Closed 14 years ago
Non-chrome XUL overlays can create JSObjects in the wrong compartment.
Categories
(Core :: XUL, defect)
Core
XUL
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
blocking2.0 | --- | betaN+ |
People
(Reporter: jst, Assigned: jst)
References
Details
(Whiteboard: [hardblocker], fixed-in-tracemonkey)
Attachments
(2 files)
1.70 KB,
patch
|
bzbarsky
:
review+
|
Details | Diff | Splinter Review |
1.72 KB,
patch
|
jst
:
review+
|
Details | Diff | Splinter Review |
This came out of bug 603535 where if you force that extension to install into a trunk build (at least on linux) you'll hit a compartment mismatch assertion trying to execute a script from an overlay. The overlay gets a codebase principal based on its url (jar:file:///... in this case), and thus operates in a compartment different from the chrome document for which the overlay is for, and then when we go to compile a script we do that in the context from the overlay with the principals of the containing XUL document.
Assignee | ||
Comment 1•14 years ago
|
||
Attachment #484931 -
Flags: review?(bzbarsky)
Assignee | ||
Updated•14 years ago
|
Assignee: nobody → jst
Assignee | ||
Updated•14 years ago
|
Status: NEW → ASSIGNED
Comment 3•14 years ago
|
||
And the point is that the overlay is not being loaded from a chrome:// URI?
Comment 4•14 years ago
|
||
Comment on attachment 484931 [details] [diff] [review] Give overlays the principal of the containing document. r=me
Attachment #484931 -
Flags: review?(bzbarsky) → review+
Assignee | ||
Comment 5•14 years ago
|
||
I tried to land this but it bounced, so I had to back out. http://hg.mozilla.org/mozilla-central/rev/312bbc3ed894 http://hg.mozilla.org/mozilla-central/rev/37b59596c539 This caused problems like this: TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/components/preferences/tests/browser_privacypane_1.js | history mode menulist should exist TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/components/preferences/tests/browser_privacypane_1.js | history mode pane should exist TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/components/preferences/tests/browser_privacypane_1.js | Test timed out TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/components/preferences/tests/browser_privacypane_2.js | Test timed out TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/components/preferences/tests/browser_privacypane_3.js | Test timed out TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/components/preferences/tests/browser_privacypane_4.js | Test timed out TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/components/preferences/tests/browser_privacypane_5.js | Test timed out TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/components/preferences/tests/browser_privacypane_6.js | Test timed out TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/components/preferences/tests/browser_privacypane_7.js | Test timed out TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/components/preferences/tests/browser_privacypane_8.js | Test timed out TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/components/privatebrowsing/test/browser/browser_privatebrowsing_beforeunload_enter.js | Incorrect number of tabs after transition into private browsing - Got 3, expected 1 TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/components/privatebrowsing/test/browser/browser_privatebrowsing_beforeunload_enter.js | Test timed out TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/components/privatebrowsing/test/browser/browser_privatebrowsing_beforeunload_enter.js | Found a tab after previous test timed out: data:text/html,<body%20onbeforeunload='return%20false;'>second</body> TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/components/privatebrowsing/test/browser/browser_privatebrowsing_beforeunload_enter.js | Found a tab after previous test timed out: data:text/html,<body%20onbeforeunload='return%20false;'>first</body> TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/components/privatebrowsing/test/browser/browser_privatebrowsing_beforeunload_exit.js | Incorrect number of tabs after transition into private browsing - Got 1, expected 3 TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/components/privatebrowsing/test/browser/browser_privatebrowsing_beforeunload_exit.js | Test timed out
Assignee | ||
Updated•14 years ago
|
Whiteboard: hardblocker
Assignee | ||
Comment 7•14 years ago
|
||
I think I found the reason for the test failures when this initially landed, the patch doesn't pass the load group to NS_NewChannel() like we used to do when calling through the helper NS_OpenURI(). Fixing that fixes the failures locally, waiting on try results now...
Assignee | ||
Updated•14 years ago
|
Whiteboard: hardblocker → [hardblocker]
Assignee | ||
Updated•14 years ago
|
Blocks: compartmentGC
Assignee | ||
Comment 8•14 years ago
|
||
This passes try and fixes the leaks that were found in my last attempt (final verdict still pending). The difference from the original patch is that we pass the load group to the channel, and we don't return early, but rather fall into the falilure case below this code, like the old code did. That's key to not leaking in this code. Carrying bz's review forward as the major change here is identical to the original patch.
Attachment #501890 -
Flags: review+
Comment 9•14 years ago
|
||
http://hg.mozilla.org/tracemonkey/rev/f93c5678d642
Whiteboard: [hardblocker] → [hardblocker], fixed-in-tracemonkey
Assignee | ||
Comment 10•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/f93c5678d642
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•