1132767 - Add a way to opt out of shims for a JS sandbox for an add-on that otherwise gets shimmed

Status: RESOLVED WONTFIX

(Core :: DOM: Content Processes, defect)

Description

[Dave Townsend [:mossop]]

The SDK modules are slowly being made e10s compliant. Some already are but since others aren't shims are enabled for SDK add-ons. The problem is that in some cases this means that shims cause sync and CPOW traffic that is unnecessary. For example the page-mod changes will have it listening to "document-element-inserted" for new windows, it has to do this in the main process to catch non-remote pages and the child process. When we register in the main process though the shims step in and also send us CPOWs from the child. This causes some jank.

It would be great to be able to flag a specific sandbox as not needing shims. We can add some kind of whitelist to the SDK loader so it can set something on the sandbox to stop this.

Gabor, Bill said you might want to do this?

Comment 1

[Dave Townsend [:mossop]]

Actually I need to think on this some more before we implement. I just remembered that while some modules are e10s safe, the modules we use to talk to the observer service are shared amongst others too so we can't just make them opt-out.

Comment 2

[Gabor Krizsanits (INACTIVE)]

Dave, if I understand this bug correctly then, it's adding a flag for the sandbox constructor to waive the shims. Since this is platform work should we triage this bug for e10s? I think I could get this done relatively easily, just an extra flag that we take into account when we decide if the object needs an AddonWrapper.

Comment 3

[Dave Townsend [:mossop]]

Thinking more I don't think this is something that would be helpful, sorry for the trouble.