425232 - NS_ERROR_XPC_SECURITY_MANAGER_VETO appears in ff2.0.0.13/ff3, but not in 2.0.0.12

Status: RESOLVED DUPLICATE of bug 390788

(Firefox :: Extension Compatibility, defect)

Description

[Grant Harding]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12

This is rather vague, but I'm a little clueless on what I should be looking at.

FF 2.0.0.12 worked fine. FF 2.0.0.13 and FF 3 (tested on b4, probably same issue on earlier betas) throw this exception:

Error: [Exception... "Security Manager vetoed action"  nsresult: "0x80570027 (NS_ERROR_XPC_SECURITY_MANAGER_VETO)"  location: "JS frame :: icons :: init :: line 787"  data: no]
Source File: icons
Line: 787

Extension URL: http://www.getfarky.com/xpi/farky_1.1.9.xpi

The offending code is:

this._controller.registerHeadline(this, this.isHidden);

which can be viewed on line 787 here: http://trac.cogjam.com/projects/farky/browser/farky/trunk/content/headlines_xbl.xml?rev=36

code for the controller is here:
http://trac.cogjam.com/projects/farky/browser/farky/trunk/content/headlines.js?rev=36

Reproducible: Always

Steps to Reproduce:
1. Install farky
2. Visit fark.com
3. Watch it throw an exception that looks like this:
Error: [Exception... "Security Manager vetoed action"  nsresult: "0x80570027 (NS_ERROR_XPC_SECURITY_MANAGER_VETO)"  location: "JS frame :: icons :: init :: line 787"  data: no]
Source File: icons
Line: 787
Actual Results:  
Headline processing for fark.com breaks after trying (and failing) to parse one row due to the exception being thrown, breaking functionality.

Expected Results:  
this._controller should end up with an array of "icons", which enabled headline filtering on fark.com (the little icons at the very top that show up after the page loads).

Breaks in 2.0.0.13 and FF3 on multiple platform (had reports from Linux users. Myself, I've tried it on Windows XP and OSX).

The only thing I've noticed is that the constructors on the bindings fire at different times. I'm wondering if something is getting defined at the wrong time now, but I'm not really sure what I can do about that (or if it's even my problem).

I'm sorry if this isn't the clearest bug report. I'm happy to provide more information if I know what's needed!

Comment 1

[Daniel Veditz [:dveditz]]

A new throw of this exception was added to fix bug 384750, although there were a couple of other related check-ins that might then use this code.

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-03-06+17%3A57&maxdate=2008-03-06+18:00&cvsroot=%2Fcvsroot

Comment 2

[Thomas K. (:tom)]

Duplicate of bug 423890 ?

Comment 3

[Daniel Veditz [:dveditz]]

jst, mrbkap: is this a bug in the restrictions added in bug 384750, or is it likely that this extension (and others) were stumbling onto potentially unsafe actions? That is, do we need to fix a regression or do we need to update dev docs so people can avoid the problem?

Comment 4

[Daniel Veditz [:dveditz]]

duplicate of trunk-fixed regression 390788, which we'll fix on branch.