Observers do not work on FF3 if the passed in object is a function

RESOLVED INVALID

Status

()

Core
XPConnect
--
major
RESOLVED INVALID
10 years ago
10 years ago

People

(Reporter: mkaply, Assigned: Brian Crowder)

Tracking

({regression})

unspecified
x86
Windows XP
regression
Points:
---
Bug Flags:
blocking1.9 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

10 years ago
Created attachment 314154 [details]
Testcase (I hope)

In the past I had written my extension in a variable like:

var foo = {
/* EXTENSION CODE */
}
foo.init();

I'm switching to:

(function () {
/* EXTENSION CODE */
)();

And I found that calls to add observers passing in the this pointer no longer work. They give:

[Exception... "Could not convert JavaScript argument arg 0 [nsIObserverService.addObserver]"  nsresult: "0x80570009 (NS_ERROR_XPC_BAD_CONVERT_JS)"  location: "JS frame :: chrome://msft_activities/content/activities.js :: anonymous :: line 7"  data: no]

The code works fine in FF2, and it works if I use a var for this.
(Reporter)

Comment 1

10 years ago
Created attachment 314155 [details]
forgot script tags
Attachment #314154 - Attachment is obsolete: true
(Reporter)

Comment 2

10 years ago
Note you must set signed.applets.codebase_principal_support to true to use the testcase, but I have verified different behavior between FF2 and FF3.
(Reporter)

Updated

10 years ago
Flags: blocking1.9?
(Reporter)

Comment 3

10 years ago
I tried to look at a regression range, but looking at the first a1 build I could find from:

April 7, 2006 at 4AM, the error happens, but with a new profile on FF2, I don't see the problem. 

I guess it's possible this was broke in FF2 and fixed in a point release. Doing some more checking.
(Reporter)

Comment 4

10 years ago
OK, so looking through history, this was broke on the trunk before FF2 branched. So my guess is something was changed on the FF2 branch that didn't make it to trunk.

Here's what I have found so far:

2006-01-03-16-trunk (1.6a1) - get error
2006-04-07-04-trunk (3.0a1) - get error

Firefox 2.0 official shipped - do not get error.
(Reporter)

Comment 5

10 years ago
OK, Tracked down when it was fixed on the branch.

It was fixed between:

 2006-05-19-08-mozilla1.8

and

 2006-05-20-04-mozilla1.8

Looking at bonsai, nothing jumps out at me.

Here's a link that goes the day before and the day after:

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=2006-05-18&maxdate=2006-05-21&cvsroot=%2Fcvsroot

As there is a work around (i.e., using a var), this doesn't seem like it would block the release.  Please re-nom if you disagree and give clear reasons why this should block.
Flags: blocking1.9? → blocking1.9-
(Reporter)

Comment 7

10 years ago
Workaround or not, this is a regression that could hit extension developers.

My primary motivation is that this is a clear regression from Firefox 2 to Firefox 3.
Flags: blocking1.9- → blocking1.9?
Someone please break in the place(s) that throw the bad-convert exception and see why it's being thrown.

/be
(Assignee)

Updated

10 years ago
Assignee: nobody → crowder
OK.  We'll block on this to investigate.  Thanks for pushing back. Much
appreciated.


Flags: blocking1.9? → blocking1.9+
(Assignee)

Comment 10

10 years ago
The exception is being thrown from XPCWrappedNative::CallMethod

2211	        if(!XPCConvert::JSData2Native(ccx, &dp->val, src, type,
2212	                                      useAllocator, &param_iid, &err))
2213	        {
2214	            ThrowBadParam(err, i, ccx);
2215	            goto done;
2216	        }

Still checking this out, but though I'd post an update.
(Assignee)

Comment 11

10 years ago
(adding bsmedberg and jst to CCs as bsmedberg helped with diagnostic and jst added nsIObserver to nsGlobalWindow for the branch)

Thanks to bsmedberg for help tracking this down.  I think we can safely call this bug INVALID, but here's the situation (hopefully bsmedberg will correct me if I am incorrect, incomplete, or imprecise):

On fx2, nsGlobalWindow implements nsIObserver.  It does not do so on Fx3, which causes the addObserver(this, ...) pattern to throw after a failed QI()

If this isn't invalid, then perhaps nsGlobalWindow -should- implement nsIObserver?
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.