1181070 - category registrations from add-on manifests are not used in the content process (there is no way to register for category manager notifications in the content process from manifest files)

Status: RESOLVED WONTFIX

(Toolkit :: Startup and Profile System, defect)

Description

[:Gijs (he/him)]

Filed in response to some IRC chatter:

[09:57:51]	mx	Can someone tell me why my XPCOM component's shouldLoad method is not called for inline content? My code: http://stackoverflow.com/q/31250009/750330
[09:57:53]	freonbot	[ firefox - XPCOM component that extends nsIContentPolicy - Stack Overflow ] - stackoverflow.com

<snip my own unhelpful suggestion>

[10:11:49]	The_8472	if you are on e10s you have to register the content policy in each content process
[10:12:53]	mx	The chrome.manifest is not enough? How do I register it in each content process?
[10:13:56]	The_8472	haven't worked with chrome manifest, i register that stuff at runtime
[10:14:57]	The_8472	https://developer.mozilla.org/en-US/Firefox/Multiprocess_Firefox/Message_Manager/Process_scripts
[10:14:59]	freonbot	[ Process scripts - Mozilla | MDN ] - developer.mozilla.org
[10:16:14]	The_8472	and then you can use the category manager to register the content policy
[10:16:54]	The_8472	but to figure out whether this actually is an e10s problem (certainly sounds like one) you can just turn e10s off and see if that changes things
[10:23:16]	mx	You are right, when I disable e10s the shouldLoad method is called for inline content and images are blocked as expected. Thank you very much, I'm gonna try what you have suggested.
[10:26:17]	Gijs	mx: The_8472: filing a bug about this, can I quote this IRC convo?
[10:26:30]	mx	yes
[10:26:45]	The_8472	that's not a bug, it's expected, sort of
[10:27:43]	The_8472	https://developer.mozilla.org/en-US/Firefox/Multiprocess_Firefox/Limitations_of_chrome_scripts#nsIContentPolicy
[10:27:52]	freonbot	[ Limitations of chrome scripts - Mozilla | MDN ] - developer.mozilla.org
[10:28:45]	The_8472	there's a compatibility shim for backwards compatibility, but I suspect that doesn't apply to whatever mx is doing for one reason or another. the correct way is to register the content policy in the content process.
[10:29:23]	Gijs	The_8472: there is no reason we can't make the chrome registration method work for content in a transparent fashion.
[10:30:12]	Gijs	either with a new "content-category" thing, or by automatically doing that for the existing directives

Mike, ideas on how hard this is / whether we can do it for v1 / who would know more about this?

Comment 1

[Benjamin Smedberg]

This is intentional. Content policy really just needs to be redesigned mostly from scratch for e10s, but we certainly don't want addon components to be loaded into a content process unless the addon explicitly loads them (and deals with unloading).

I'd strongly like to WONTFIX this, but I'm going to wait for mconley's assent.

Comment 2

[Dave Townsend [:mossop]]

Possibly a dupe of bug 1131065

Comment 3

[:Gijs (he/him)]

(In reply to Dave Townsend [:mossop] (PTO till July 21st) from comment #2)
> Possibly a dupe of bug 1131065

Definitely related. Whether it's a dupe depends on whether we think applying any / all of these directives should be opt-in for the content process.

Comment 4

[Mike Conley (:mconley) (:⚙️)]

Our shim layer doesn't work with components registered via chrome.manifest (see bug 1110123 for another example of this). I believe supporting chrome.manifest registration was deemed "not worth it" in that bug.

If mx wants to take advantage of the shims, they'll need to register in script.

So I think this is a WONTFIX.