390788 - Accessing innerWidth of a tabbrowser contentWindow throws NS_ERROR_XPC_SECURITY_MANAGER_VETO

Status: RESOLVED FIXED

(Core :: XPConnect, defect)

Description

[Frank Wein [:mcsmurf]]

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?

Comment 1

[Frank Wein [:mcsmurf]]

Blake: Can you comment on this bug if it is a valid bug? I'm not sure if it is...

Comment 2

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Fix

Given other bugs, I'm rapidly losing faith in EnsureLegalActivity, but this patch will make it deal for now.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 275200 [details] [diff] [review]
Fix

OK, I buy this.

Comment 4

[Blake Kaplan (:mrbkap) (inactive)]

Fix checked into trunk.

Comment 5

[Boris Zbarsky [:bzbarsky]]

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#

Comment 6

[Boris Zbarsky [:bzbarsky]]

And this could really use an automated testcase.  Should be simple to mochitest, no?

Comment 8

[Johnny Stenback (:jst)]

Comment on attachment 275200 [details] [diff] [review]
Fix

This patch applies to the branch as well, and fixes the bug there too.

Comment 9

[Daniel Veditz [:dveditz]]

Comment on attachment 275200 [details] [diff] [review]
Fix

Approved for 1.8.1.15, a=dveditz for release-drivers

Comment 10

[Johnny Stenback (:jst)]

Fix landed on the branch.

Comment 11

[Nick Thomas [:nthomas] (UTC+12)]

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 ?

Comment 12

[Ben Turner (not reading bugmail, use the needinfo flag!)]

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.

Comment 13

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Relanded, all green.

Comment 14

[Daniel]

When can we expect to see this fix in a release version?

Comment 15

[Nick Thomas [:nthomas] (UTC+12)]

Daniel, it's in Firefox 2.0.0.15, which is aimed at the end of June, and has been in Firefox 3.0 since the betas.

Comment 16

[Daniel]

(In reply to comment #15)
> Daniel, it's in Firefox 2.0.0.15, 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.

Comment 17

[Hasham]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.15pre) Gecko/20080610 BonEcho/2.0.0.15pre

Verified for 1.8.1.15 branch. No error message in console.