Closed Bug 1494709 Opened 6 years ago Closed 6 years ago

Firefox only looks for NativeMessagingHosts in Native registry view on windows


(Toolkit :: Add-ons Manager, enhancement)

Windows 10
Not set



Tracking Status
firefox64 --- fixed


(Reporter: cpuchip, Assigned: molly)



(Keywords: dev-doc-complete, Whiteboard: [specification][type:bug])


(1 file)

What did you do?
1. Install a 32 bit Native Messaging Host on 64 Bit windows for 64 Bit / 32 Bit Firefox and Chrome ( )
2. Installed our addon extension ( )
3. Tried to launch the Native Messaging Host from our extension on a web page ( )
4. Native Message Host not found due to wrong location in registry. ( Discovered using reg lookups with procmon )

What happened?
We've created a 32bit Native Messaging Host for Firefox and Chrome. Which we are utilizing from an extension in Firefox and Chrome. We support system wide installer for enterprise deployments of our extension at school districts.

When trying to lunch our Native Message Host, Firefox looks for our Native Message host in Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\NativeMessagingHosts\com.gradecam.firewyrmhost


What should have happened?
Since we've installed a 32 bit Native Message host on 64 bit windows using a system wide 32bit MSI installer we cannot set a registry key in the Native view of the registry: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\NativeMessagingHosts\com.gradecam.firewyrmhost

We are forced to store it here:

Chrome has no trouble looking for NativeMessageHosts in both the native view and the redirected view of the registry. Please add a lookup for Native messages hosts from the WOW6432Node path too.

Is there anything else we should know?
I know your documentation states that you only look up Native Messaging Hosts in the native view of the registry and you give a work around by passing the KEY_WOW64_64KEY or KEY_WOW64_32KEY flags into RegCreateKeyEx, That isn't possibly in an msi installer (As far as I know) We are using WIX. The relevant link to your documentation is:
I'm moving this to Firefox : Untriaged, so that there is a better chance that the Add-ons engineers will see it. If the Firefox version is relevant, please add it to the bug report.

There are links to the Add-ons mailing list and IRC channels on:
Component: API → Untriaged
OS: Other → Windows 10
Product: → Firefox
Hardware: All → x86_64
Component: Untriaged → Add-ons Manager
Product: Firefox → Toolkit
Matt, I don't know much about the Windows registry and am having trouble evaluating this.  You helped us out with a related issue before (bug 1282680), can you offer some advice here?
Flags: needinfo?(mhowell)
I don't know how to add versions to the bug, But I tested with Firefox 55, 62.0.2, and Firefox 63.? beta the release beta as of when the bug was reported.
Well, we are correctly following what our documentation says, but that differs from what Chrome's documentation ( says about the same feature, which is "first the 32-bit registry is queried, then the 64-bit registry." We only check the 64-bit registry on 64-bit machines. I'm not an addons person, but my thinking is that we would want to try to be compatible with Chrome's behavior here.

The thing is, I'm not sure why we did it differently from Chrome in the first place, and I'd prefer to understand that before I recommend changes. It looks like our behavior was in place in our original Windows implementation from bug 1270359, and there's a brief mention there of the issue, but there's no discussion about it. I don't know if this was discussed offline somewhere or if there just wasn't enough awareness of this issue at the time. Andrew, do you remember any specific reasoning or discussion around this? If there isn't a specific reason why it's the way it is, then I would recommend changing our behavior to match Chrome's.
Flags: needinfo?(mhowell) → needinfo?(aswan)
The only previous discussion I recall was around
I don't have enough hands-on experience with Windows to have an informed opinion about the right outcome here.
Flags: needinfo?(aswan)
Oh good, I'm arguing with myself, that's cool and not embarrassing at all. /s

Comment 0 here indicates that always registering in the native key is more trouble for extension authors than I anticipated it would be. I've done a little bit of work with WIX, so I would bet that it has some way to get around this problem, but it's not always easy to get WIX to go off the beaten path. If we can prevent the need for that, I'd like to. Another bad sign is that our documentation makes the assumption that developers are writing their own calls to the Windows C API function RegCreateKeyEx in their installers; actually, there's almost always some installer framework that's really responsible for that, but this is the only general method that we can document for controlling the registry view. That indicates that we might be better off losing the requirement for controlling the registry view.

Bottom line, I think we should implement this suggestion. I apologize for reversing my old position, but I now think that the inconvenience we're creating is not worth it. I'll volunteer to write the patch, it should be very small.
Assignee: nobody → mhowell
Ever confirmed: true
This brings us into line with Chrome's behavior. Like Chrome, we check the
32-bit view first and check HKEY_CURRENT_USER before HKEY_LOCAL_MACHINE.

This patch only adds code affecting HKEY_LOCAL_MACHINE because the registry
does not use a 32-bit view in the HKEY_CURRENT_USER\Software key.
Ha, no need for self-flagellation, there was consensus about the original approach back in bug 1282680.
Thanks for the quick fix!
Keywords: dev-doc-needed
Pushed by
Check for native messaging host registrations in both the 32-bit and 64-bit registry views. r=aswan
No problem, thanks for the quick review!
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
Wow! Thanks for putting that together so quickly. Do you know when I would see this fix in the beta channel/release?

We totally appreciate helping us make our jobs a lot easier over here!
We landed the change in nightly version 64, so it will come along with that version when it moves to beta on October 22, and then to release on December 11, according to
Excellent. Thank you for the info and great work.
I'm not sure what web-developer-facing features need to be documented as a result of this bug. Can you give me an explanation? Thanks!
Flags: needinfo?(aswan)
I just went ahead and made the edit to myself (and requested editorial review because I am no technical writer).
Flags: needinfo?(aswan)
(In reply to Matt Howell [:mhowell] from comment #16)
> I just went ahead and made the edit to
> Native_manifests myself (and requested editorial review because I am no
> technical writer).

OK, perfect, thanks Matt! I've checked it out, and your edits look good. I've also added a note to the Fx 64 rel notes about this:
You need to log in before you can comment on or make changes to this bug.