Last Comment Bug 390788 - Accessing innerWidth of a tabbrowser contentWindow throws NS_ERROR_XPC_SECURITY_MANAGER_VETO
: Accessing innerWidth of a tabbrowser contentWindow throws NS_ERROR_XPC_SECURI...
: regression, verified1.8.1.15
Product: Core
Classification: Components
Component: XPConnect (show other bugs)
: Trunk
: x86 Windows XP
: -- normal (vote)
: ---
Assigned To: Blake Kaplan (:mrbkap)
: 425232 (view as bug list)
Depends on:
Blocks: 384750
  Show dependency treegraph
Reported: 2007-08-03 05:53 PDT by Frank Wein [:mcsmurf]
Modified: 2008-06-12 10:55 PDT (History)
13 users (show)
dveditz: blocking1.8.1.15+
dveditz: wanted1.8.1.x+
bzbarsky: in‑testsuite?
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Fix (1.11 KB, patch)
2007-08-03 16:31 PDT, Blake Kaplan (:mrbkap)
bzbarsky: review+
bzbarsky: superreview+
dveditz: approval1.8.1.15+
jst: approval1.9+
Details | Diff | Splinter Review

Description Frank Wein [:mcsmurf] 2007-08-03 05:53:39 PDT
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 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 :: :: 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:

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] 2007-08-03 07:13:57 PDT
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) 2007-08-03 16:31:24 PDT
Created attachment 275200 [details] [diff] [review]

Given other bugs, I'm rapidly losing faith in EnsureLegalActivity, but this patch will make it deal for now.
Comment 3 Boris Zbarsky [:bz] 2007-08-03 19:27:20 PDT
Comment on attachment 275200 [details] [diff] [review]

OK, I buy this.
Comment 4 Blake Kaplan (:mrbkap) 2007-08-07 18:52:18 PDT
Fix checked into trunk.
Comment 5 Boris Zbarsky [:bz] 2008-04-29 10:02:13 PDT
Don't we need this on branch too?  This breaks code using <xul:iframe> (e.g. in signed script).  See the thread at
Comment 6 Boris Zbarsky [:bz] 2008-04-29 10:06:30 PDT
And this could really use an automated testcase.  Should be simple to mochitest, no?
Comment 7 Daniel Veditz [:dveditz] 2008-04-30 11:28:20 PDT
*** Bug 425232 has been marked as a duplicate of this bug. ***
Comment 8 Johnny Stenback (:jst, 2008-06-05 14:10:41 PDT
Comment on attachment 275200 [details] [diff] [review]

This patch applies to the branch as well, and fixes the bug there too.
Comment 9 Daniel Veditz [:dveditz] 2008-06-05 14:44:22 PDT
Comment on attachment 275200 [details] [diff] [review]

Approved for, a=dveditz for release-drivers
Comment 10 Johnny Stenback (:jst, 2008-06-05 17:29:44 PDT
Fix landed on the branch.
Comment 11 Nick Thomas [:nthomas] 2008-06-06 06:46:12 PDT
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/ 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.
LayoutPerformanceLocalTest: test failed

cycler.html is here in mxr:

Several seamonkey boxes are also having issues:

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!) 2008-06-06 17:37:47 PDT
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!) 2008-06-06 21:18:20 PDT
Relanded, all green.
Comment 14 Daniel 2008-06-12 01:20:43 PDT
When can we expect to see this fix in a release version?
Comment 15 Nick Thomas [:nthomas] 2008-06-12 02:43:28 PDT
Daniel, it's in Firefox, which is aimed at the end of June, and has been in Firefox 3.0 since the betas.
Comment 16 Daniel 2008-06-12 02:47:04 PDT
(In reply to comment #15)
> Daniel, it's in Firefox, 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 2008-06-12 10:55:57 PDT
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20080610 BonEcho/

Verified for branch. No error message in console.

Note You need to log in before you can comment on or make changes to this bug.