Accessing innerWidth of a tabbrowser contentWindow throws NS_ERROR_XPC_SECURITY_MANAGER_VETO To reproduce: 0. Fetch a Firefox(!) trunk build 1. Switch signed.applets.codebase_principal_support to true so that a webpage from content can request privs 2. Open any website in the first tab and https://bugzilla.mozilla.org/attachment.cgi?id=238226 in any other tab, make sure you trust the code from that testcase (it's a drawWindow canvas testcase) 3. Click on Draw to get a preview of the page in tab 1 in the canvas below 4. Observe that you get no preview but instead a error in the Error Console: Error: uncaught exception: [Exception... "Security Manager vetoed action" nsresult: "0x80570027 (NS_ERROR_XPC_SECURITY_MANAGER_VETO)" location: "JS frame :: https://bugzilla.mozilla.org/attachment.cgi?id=238226# :: doFrob :: line 26" data: no] Line 26 is a empty line, but by adding some line breaks I found out that it actually seems to mean line 27. This regressed between 2007-07-05-04 and 2007-07-06-04. Bonsai link: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-07-05+03%3A00&maxdate=2007-07-06+04%3A00&cvsroot=%2Fcvsroot This points to Bug 384750, but I'm not sure because that's a security bug. It looks like DOMi had a similar problem, see Bug 387053, but that patch was backed out again as Bug 387084 was fixed. So is this now a real bug or a bug in the testcase?
Blake: Can you comment on this bug if it is a valid bug? I'm not sure if it is...
Created attachment 275200 [details] [diff] [review] Fix Given other bugs, I'm rapidly losing faith in EnsureLegalActivity, but this patch will make it deal for now.
Comment on attachment 275200 [details] [diff] [review] Fix OK, I buy this.
Attachment #275200 - Flags: approval1.9? → approval1.9+
Fix checked into trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Don't we need this on branch too? This breaks code using <xul:iframe> (e.g. in signed script). See the thread at http://groups.google.com/group/mozilla.dev.security/browse_frm/thread/200083a2d0cb1562#
And this could really use an automated testcase. Should be simple to mochitest, no?
Comment on attachment 275200 [details] [diff] [review] Fix This patch applies to the branch as well, and fixes the bug there too.
Attachment #275200 - Flags: approval184.108.40.206?
Attachment #275200 - Flags: approval220.127.116.11? → approval18.104.22.168?
Comment on attachment 275200 [details] [diff] [review] Fix Approved for 22.214.171.124, a=dveditz for release-drivers
Attachment #275200 - Flags: approval126.96.36.199? → approval188.8.131.52+
Fix landed on the branch.
The mac tinderbox started burning after this bug and bug 418996 and bug 424426 landed on the branch (bm-xserve05). It's failing the Tp2 test: Running LayoutPerformanceLocalTest test ... Timeout = 180 seconds. Begin: Thu Jun 5 18:08:31 2008 cmd = /builds/tinderbox/Fx-Mozilla1.8-Nightly/Darwin_8.7.0_Depend/mozilla/../build/unifox/dist/BonEcho.app/Contents/MacOS/firefox-bin http://localhost/pageload/cycler.html Process killed. Took 2 seconds to die. End: Thu Jun 5 18:11:32 2008 ----------- Output from LayoutPerformanceLocalTest ------------- ----------- End Output from LayoutPerformanceLocalTest --------- LayoutPerformanceLocalTest: firefox-bin successfully stayed up for 180 seconds. TinderboxPrint:Tp2:[CRASH] LayoutPerformanceLocalTest: test failed cycler.html is here in mxr: http://mxr.mozilla.org/seamonkey/source/tools/performance/pageload/cycler.html?raw=1 Several seamonkey boxes are also having issues: http://tinderbox.mozilla.org/showbuilds.cgi?tree=Mozilla1.8-SeaMonkey&maxdate=1212719731&hours=12 Are these tests broken by the set of changes or has this caught a regression ?
Backed out of branch to see if the orange clears. I'll be watching it over the weekend and will try to reland before Monday.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Relanded, all green.
Status: REOPENED → RESOLVED
Last Resolved: 11 years ago → 11 years ago
Resolution: --- → FIXED
When can we expect to see this fix in a release version?
Daniel, it's in Firefox 184.108.40.206, which is aimed at the end of June, and has been in Firefox 3.0 since the betas.
(In reply to comment #15) > Daniel, it's in Firefox 220.127.116.11, which is aimed at the end of June, and has > been in Firefox 3.0 since the betas. > Thanks. Looks like it might be a plugin issue on my end instead then. My bad.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:18.104.22.168pre) Gecko/20080610 BonEcho/22.214.171.124pre Verified for 126.96.36.199 branch. No error message in console.
Keywords: fixed188.8.131.52 → verified184.108.40.206
You need to log in before you can comment on or make changes to this bug.