Michael Stufflebeam Reporter
	Description • 6 years ago

What did you do?
================
1. Install a 32 bit Native Messaging Host on 64 Bit windows for 64 Bit / 32 Bit Firefox and Chrome ( https://downloads.gradecam.com/plugin/beta/win-enterprise2 )
2. Installed our addon extension ( https://addons.mozilla.org/en-US/firefox/addon/gradecam-helper/?src=search )
3. Tried to launch the Native Messaging Host from our extension on a web page ( https://downloads.gradecam.com/sdk/alpha/examples/webcam_scanner_demo.html )
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:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Mozilla\NativeMessagingHosts\com.gradecam.firewyrmhost

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: 
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Native_manifests#Windows

	John Whitlock [:jwhitlock]
	Comment 1 • 6 years ago

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:

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions

	Andrew Swan [:aswan]
	Comment 2 • 6 years ago

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?

	Michael Stufflebeam Reporter
	Comment 3 • 6 years ago

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.

	Molly Howell (she/her) (no longer active) Assignee
	Comment 4 • 6 years ago

Well, we are correctly following what our documentation says, but that differs from what Chrome's documentation (https://developer.chrome.com/extensions/nativeMessaging#native-messaging-host-location) 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.

	Andrew Swan [:aswan]
	Comment 5 • 6 years ago

The only previous discussion I recall was around https://bugzilla.mozilla.org/show_bug.cgi?id=1282680#c6
I don't have enough hands-on experience with Windows to have an informed opinion about the right outcome here.

	Molly Howell (she/her) (no longer active) Assignee
	Comment 6 • 6 years ago

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.

	Molly Howell (she/her) (no longer active) Assignee
	Comment 7 • 6 years ago

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.

	Andrew Swan [:aswan]
	Comment 8 • 6 years ago

Ha, no need for self-flagellation, there was consensus about the original approach back in bug 1282680.
Thanks for the quick fix!

	Pulsebot
	Comment 9 • 6 years ago

Pushed by mhowell@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/3be82e46d044
Check for native messaging host registrations in both the 32-bit and 64-bit registry views. r=aswan

	Molly Howell (she/her) (no longer active) Assignee
	Comment 10 • 6 years ago

No problem, thanks for the quick review!

	Natalia Csoregi [:nataliaCs]
	Comment 11 • 6 years ago
bugherder

https://hg.mozilla.org/mozilla-central/rev/3be82e46d044

	Michael Stufflebeam Reporter
	Comment 12 • 6 years ago

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!

	Molly Howell (she/her) (no longer active) Assignee
	Comment 13 • 6 years ago

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 https://wiki.mozilla.org/Release_Management/Calendar.

	Michael Stufflebeam Reporter
	Comment 14 • 6 years ago

Excellent. Thank you for the info and great work.

	Chris Mills [:cmills]
	Comment 15 • 6 years ago

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!

	Molly Howell (she/her) (no longer active) Assignee
	Comment 16 • 6 years ago

I just went ahead and made the edit to https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Native_manifests myself (and requested editorial review because I am no technical writer).

	Chris Mills [:cmills]
	Comment 17 • 6 years ago

(In reply to Matt Howell [:mhowell] from comment #16)
> I just went ahead and made the edit to
> https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/
> 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:
https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/64#Manifest_changes