Open Bug 1574446 Opened 4 months ago Updated Last month

mozrunner checks wrong Windows registry location for Firefox binary, depending on geckodriver bit architecture

Categories

(Testing :: Mozbase Rust, defect, P3)

Version 3
defect

Tracking

(Not tracked)

ASSIGNED

People

(Reporter: ato, Assigned: ato)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Windows ships with a 32-bit compatibility layer which means you can
run 32-bit programs on a 64-bit system installation of Windows.
Some users use the 32-bit releases of geckodriver on 64-bit systems,
and this causes problems when mozrunner tries to deduce the default
location of the Firefox binary.

Quoting whimboo in
https://github.com/mozilla/geckodriver/issues/1168:

the problem here is that a 32bit executable of geckodriver will
check a different path in the Registry than the 64bit one. As
such a 64bit installation of Firefox cannot be found. It might be
similar vice versa. As such we always might have to check for both
a 32bit and 64bit installation of Firefox.

This was originally filed as
https://github.com/mozilla/geckodriver/issues/1045 on GitHub, then
migrated to https://github.com/jgraham/rust_mozrunner/issues/15,
but we lost track of this issue when bug tracking for the mozbase
Rust port was moved to Bugzilla.

The suggestion from florentbr to check a single registry path
that is shared between 32- and 64-bit systems seems sensible.

Assignee: nobody → ato
Status: NEW → ASSIGNED

The current lookup for the Firefox executable on Windows exhibits
two problems: it relies on architecture specific paths (such
as Wow6432Node), and it skips looking at HKEY_CURRENT_USER for
applications that are not installed system-wide.

The first problem manifests when using the 32-bit version of
geckodriver on a 64-bit host system, or when the Firefox executable
has a different architecture than geckodriver.

The second issue is that mozrunner entirely ignores user-specific
installations of Firefox.

This patch looks at the two following keys, which seems to more
reliably be able to tell us the location of the Firefox executable,
irregardless of the process executable's bitness:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\firefox.exe
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\firefox.exe

When they exist, these should return:

(Default)    REG_SZ    C:\Program Files (x86)\FirefoxESR\firefox.exe
Path    REG_SZ    C:\Program Files (x86)\FirefoxESR\firefox.exe

Fixes: https://github.com/mozilla/geckodriver/issues/1045

I’ve attached a patch for this based on the Windows Registry keys
suggested on GitHub
. It compiles fine, but since I don’t have
access to a Windows system I have not been able to test it. I will
reach out to someone on the GitHub issue ticket to ask for help on
that, using a build off try.

Blocks: 1520585

The priority flag is not set for this bug.
:jgraham, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(james)
Flags: needinfo?(james)
Priority: -- → P2
Blocks: 1573798
No longer blocks: 1520585

Andreas, would you mind creating new try builds for testing it on both 32 and 64 systems? You can use the toolchain builds when pushing to try. Thanks.

Flags: needinfo?(ato)

The patch isn't working, and it actually doesn't hard-block the 0.26.0 release which we want to ship soon. So moving to 0.27.0.

Blocks: 1584911
No longer blocks: 1573798
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.