Closed Bug 1282680 Opened 5 years ago Closed 5 years ago
Messaging Host registry locations to include 32 & 64 bit locations
58 bytes, text/x-review-board-request
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36 Steps to reproduce: Ran Firefox 32 bit with webextension using nativeMessaging host registered in 32 bit (Wow6432Node) registry. Then ran Firefox 64 bit with same configuration. Actual results: No such native application com.MyApp this.NativeApp</this.startupPromise<() Appears 32bit Fireofx reads from 32 bit registry (WOW6432Node) 64bit Firefox reads from 64 bit registry Expected results: Addition to nativeHost registry under one of 32/64 bit registry should be sufficient. Could it follow similar to Chrome browser, where first the 32-bit registry is queried, then the 64-bit registry - regardless of which Firefox platform is being used.
Summary: Windows nativeMessagingHost registry locations to include 64 bit locations → Windows nativeMessagingHost registry locations to include 32 & 64 bit locations
definitely should be documented. ask windows expert internally about this - ramifications. needinfo someone like mark hammond or BDS to talk with andrew swan to find out if this is type of convention we should be following, or if we can just document it.
We discussed this in triage this morning and I'd like to push back on this one a bit. We're already incompatible with Chrome in that the registry keys that we consult are different from the ones Chrome uses. I'd love to keep Firefox as simple as possible and propose that native app developers who want to support their 32-bit native app with 64-bit Firefox and vice versa must explicitly create entries in both registries (and of course, we will carefully document this). More generally, I'm not familiar enough with Windows to know what existing precedents exist for handling 32-vs-64 bit issues when application A references registry keys created by application B. Ben, do you have thoughts either on the issue or on additional people to weigh in?
->mhowell. Since these pipes are not carrying binary arch-specific data but JSON, I would recommend that everyone (Firefox 32 and 64 and 3rd-party apps 32 and 64) use one common registry location, but I don't remember enough of the details of SysWOW32 compatibility layers to know exactly how that should work.
Flags: needinfo?(benjamin) → needinfo?(mhowell)
This is a nuisance but not a show stopper. As usage example, we will install 1 nativeHost app as part of our installation, and our customers want us to support installation prior to firefox install so that we cannot check if they are installing 32 bit firefox, or 64 bit firefox. Without this change we will need to register the nativeHost twice in the registry to ensure that either platform (32/64) of FF can find it. You can access a specific registry view regardless of application platform Ref accessing an alternate registry view https://msdn.microsoft.com/en-us/library/windows/desktop/aa384129(v=vs.85).aspx Ref registry keys affected by Wow64 https://msdn.microsoft.com/en-us/library/windows/desktop/aa384253(v=vs.85).aspx
There are three options that I can see: 1) Keep the present behavior. Application developers are required to explicitly confirm support for both 32- and 64-bit Firefox by placing their manifest in both locations. Since very few applications would be expected to have problems caused by the architectures of Firefox and the application being different, this is probably unnecessary work for the extension developer. 2) Check both WoW64 and native 64-bit locations. This would be compatible with Chrome's behavior (though, as comment 3 and the documentation mention, we are unable to be compatible with Chrome in other important ways). 3) Always check the "native" (non-WoW64) key. This would use the alternate registry view functionality that the documentation linked from comment 5 describes to always look in the non-WoW6432Node location, regardless of the architecture of the Firefox build or of the OS. We already use this technique for some of our internal registry entries, so the code change would be trivial. The downside is that extension developers would have to use the same view when adding the manifest, to make sure we can always find it, but at least that's all they have to do to make sure we can always find it. Personally, I like #3, because I like having a single location (per hive) that we guarantee is always used without regard for architecture, and I don't see a need to separate 32- and 64-bit in this case. No matter which option is selected, the documentation should be updated to explain the behavior. It's also worth nothing that, depending on the application, developers may be able to work around this whole situation by installing their manifest to HKEY_CURRENT_USER, where there is no WoW64 redirection, instead of to HKEY_LOCAL_MACHINE.
[Tracking Requested - why for this release]: Native messaging is going out for the first time in 50 and we need to get this behavior nailed down for that release rather than shipping something in 50 and changing it in a later version.
I agree, option #3 also sounds best to me.
Tracking 50+ based on Comment 7 - we need to come to a decision before this ships.
Option 3 sounds good to me.
Assignee: nobody → aswan
Iteration: --- → 50.4 - Aug 1
Review commit: https://reviewboard.mozilla.org/r/65044/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/65044/
Attachment #8772176 - Flags: review?(kmaglione+bmo)
This is short&sweet since our tests use MockRegistry which is blissfully unaware of hives and WoW6432 and such.
Comment on attachment 8772176 [details] Bug 1282680 Always use 64-bit registry for native messaging https://reviewboard.mozilla.org/r/65044/#review62072
Attachment #8772176 - Flags: review?(kmaglione+bmo) → review+
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/0ce39c20b706 Always use 64-bit registry for native messaging r=kmag
You need to log in before you can comment on or make changes to this bug.