1005700 - Components with Javascript Global Constructor doesn't work on Firefox 29

Status: RESOLVED INVALID

(Core :: XPConnect, defect)

Description

[Mike Kaply [:mkaply]]

Attachment: Extension that shows problem

We have an extension that worked on Firefox 29.

It exposes an object via JavaScript-global-constructor that can retrieve local file information.

It works fine on Firefox 28, but on Firefox 29 it doesn't work.

On Firefox 28, if I do an alert on the object, i see:

[xpconnect wrapped (nsISupports, nsIWorkSmartLocalFileSystem, nsISecurityCheckedComponent, nsIClassInfo)]

On Firefox 29, I just see:

[xpconnect wrapped nsISupports]

Comment 1

[Mike Kaply [:mkaply]]

Attachment: HTML file to test extension

Comment 2

[Benjamin Smedberg]

nsISecurityCheckedComponent was removed in bug 794943. And even without knowing that this bug has nothing to do with XPCOM.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Why do you need nsISecurityCheckedComponent at all here?  It shouldn't be needed, since your have DOM_OBJECT classinfo.

Comment 4

[Mike Kaply [:mkaply]]

(In reply to Boris Zbarsky [:bz] from comment #3)
> Why do you need nsISecurityCheckedComponent at all here?  It shouldn't be
> needed, since your have DOM_OBJECT classinfo.

I inherited this code, so I didn't totally understand it.

Just removing nsISecurityCheckedComponent makes things work.

I thought it would be more complicated than that. We really do need to get this change up on Firefox 29 for Add-on developers, though.

Comment 5

[Boris Zbarsky [:bzbarsky]]

> I inherited this code, so I didn't totally understand it.

That seems to be the common refrain for people using nsISecurityCheckedComponent...

> We really do need to get this change up on Firefox 29 for Add-on developers, though.

Yes, we do...

Comment 6

[Bobby Holley (:bholley)]

(In reply to Boris Zbarsky [:bz] from comment #5)
> > I inherited this code, so I didn't totally understand it.
> 
> That seems to be the common refrain for people using
> nsISecurityCheckedComponent...
> 
> > We really do need to get this change up on Firefox 29 for Add-on developers, though.
> 
> Yes, we do...

Don't we plan on making the DOM_OBJECT thing go away at some point too? Or will we have a fallback for addons? In general, it seems like we should give people the most future-proof recommendations possible.

Comment 7

[Boris Zbarsky [:bzbarsky]]

> Don't we plan on making the DOM_OBJECT thing go away at some point too?

That's unclear, precisely because it is used by addons and we don't have an alternate story yet.

We do plan to make it go away from our internal code, in favor of webidl bindings, but of course addons can't do webidl bindings in their current form...

Note that this addon was already using DOM_OBJECT classinfo, so it's not like we're actively dis-improving it by adding that, at least.

Comment 8

[Mike Kaply [:mkaply]]

We really need to make sure we have the right messaging here because we told folks "netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect") is going away, so weite add-on to emulate that functionality"

So the last thing we want to do is break the add-ons they wrote to allow the things they needed on web pages due to the remove of UniversalXPConnect.

And my wager is that a lot of these add-ons aren't on AMO, they are internal use, so we won't know about them...

Comment 9

[Bobby Holley (:bholley)]

(In reply to Mike Kaply (:mkaply) from comment #8)
> We really need to make sure we have the right messaging here because we told
> folks
> "netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect") is
> going away, so weite add-on to emulate that functionality"

Well, the addons that we were suggesting involve hooking up a content script that listens for a CustomEvent, and sending a message to chrome to do whatever interesting stuff needs to happen.

I know I'm coming late to the party here, but can we fix whatever issues prevent enterprise users from using Jetpack extensions? There's a lot of really good e10s-safe functionality in the Addon SDK, and we should try to let as many people use that as possible.

Comment 10

[Mike Kaply [:mkaply]]

(In reply to Bobby Holley (:bholley) from comment #9)
> I know I'm coming late to the party here, but can we fix whatever issues
> prevent enterprise users from using Jetpack extensions? There's a lot of
> really good e10s-safe functionality in the Addon SDK, and we should try to
> let as many people use that as possible.

Sadly no. Deploying Add-on SDK add-ons is much more problematic since they are accessible to the user and can be disabled.

You also have to modify the add-on scopes preferences.

Traditional add-ons are much easier to integrate into Firefox for deployment.