1330488 - Install the native messaging host for extensions distributed within partner repacks

Status: RESOLVED WONTFIX

(Firefox :: Installer, defect)

Description

[Hector Zhao [:hectorz]]

With extensions transitioning to WebExtensions API, certain features previously implemented in NPAPI plugins and js-ctypes would be moved to NativeMessaging, which requires a separately installed binary host.

I think it would be reasonable to have the repacked Firefox installer to also install these corresponding binaries for any bundled extensions.

Comment 1

[Molly Howell (she/her) (no longer active)]

Requesting input from someone who's worked on the native messaging feature, since I'm just the installer guy.

My understanding is that the native binary is meant to be distributed as part of some larger native application, and so the messaging host isn't really of any use on its own without that whole application.
That leaves open the possibility of extensions that just use a single binary to implement some of the extension's functionality, but that would seem to violate the intent of the native messaging feature.

If all that's correct, then I don't think having this would really help anything.

Comment 2

[Kris Maglione [:kmag]]

Yeah, that's pretty much the case.

Can you provide more details on specific use cases you have in mind?

Comment 3

[Hector Zhao [:hectorz]]

(In reply to Kris Maglione [:kmag] from comment #2)
> 
> Can you provide more details on specific use cases you have in mind?

For example, we ship a variant of IE Tab with Fx China repack, and it looks like every possible replacement would involve native messaging, and having the entension part bundled but not the helper binary would be suboptimal.

Comment 4

[Kris Maglione [:kmag]]

OK. Unfortunately, this is one use case that we definitely do not want to support. The implementation of the Chrome native messaging version of IE Tab is a fairly terrible hack, and while we can't (or at least won't) stop people from distributing it as a standalone add-on, we definitely do not want to ship it with partner distributions.

This might be suitable for distribution as a hybrid system add-on, but even in that case, we'd still need a sane way to embed the application that hosts the IE component, rather than just having it draw over top of the Firefox window. The only way we currently have to do this is NPAPI, which we don't want to continue to support.

From discussions on IRC, I think we'd be happy allowing a native window launched via native messaging to be embedded in the browser for this particular use case, but I don't know how difficult that would be to implement or support on Windows. Matt suggested that Benjamin might be a good person to comment.

Comment 5

[Benjamin Smedberg]

kmag, from a product perspective we *do* want to ship IETab as part of the China repack. I think we should find a way to do that for distribution addons if possible. Kev has the context about product requirements.

I don't know/understand how the IETab stuff actually works. I figured it shipped bits back and forth; using an actual native widget would indeed be pretty ugly.

Comment 6

[Kris Maglione [:kmag]]

I understand that we do want to ship IE Tab. My issue is with shipping the Chrome/WebExtension version as opposed to the current NPAPI version.

That version works by creating a separate OS-level window, stacking it over the Firefox window, and using native messaging to try to keep it in sync with the parent window. That is a huge step back from the current implementations.

When we talked about this on IRC, Kev agreed that this is something we don't want.

Comment 7

[Molly Howell (she/her) (no longer active)]

Seems like the addons people don't want to support this, so I'll follow their lead.