mozregression and mozregression-gui aren't using the requested profile on windows 10

NEW
Unassigned

Status

Testing
mozregression
2 years ago
3 months ago

People

(Reporter: jaws, Unassigned)

Tracking

Version 3
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

When I run mozregression with:
 mozregression --profile /c/Users/jared/AppData/Local/Mozilla/Firefox/Profiles/9rmfofkf.default

I get a Firefox instance that has no history or bookmarks that are found in the default profile.

I have also tried using `--profile-persistence reuse` but that has no difference.
ok, I just checked and this is working for me on linux, and on windows xp.

Though I am not using cygwin on windows, so the command is:

> mozregression -g 2016-01-01 -b 2016-01-03 --profile "C:\Documents and Settings\jp\Application Data\Mozilla\Firefox\Profiles\oydzotf4.default"

And this is not windows 10.

Do you have a running firefox using that profile when you try (you should not) ? Have you double checked that your directory exist and is the profile you think ?
I have tried using a profile that Firefox is not using (but Firefox is running) as well as closing Firefox and using the profile. Neither use the profile.

The path to the profile is correct, as I use tab-completion when typing in the path and cygwin completes the path. I also tried using backslashes as your example showed, but that didn't make a difference.
Comment hidden (typo)
Summary: mozregression 2.2.1 isn't using the requested profile on windows 10 → mozregression isn't using the requested profile on windows 10
Hey William, can you help me debug/fix this? It is preventing me from fixing a couple bugs as I can only reproduce them on my daily-usage profile. I have tried the following commands:

> mozregression --profile-persistence clone-first --profile "c:\Users\jared\AppData\Local\Mozilla\Firefox\Profiles\9rmfofkf.default"

> mozregression --profile-persistence clone-first --profile c:\Users\jared\AppData\Local\Mozilla\Firefox\Profiles\9rmfofkf.default

> mozregression --profile-persistence clone-first --profile /c/Users/jared/AppData/Local/Mozilla/Firefox/Profiles/9rmfofkf.default
Summary: mozregression isn't using the requested profile on windows 10 → mozregression and mozregression-gui aren't using the requested profile on windows 10
Ok so after some digging I found no problem in the profile handling code in mozregression that I could see. However, I did notice that Firefox itself doesn't seem to use the right profile on Windows 10.

Reproduction steps:

* Copy profile to a new directory (e.g. C:\Users\myuser\profilecopy)
* Start firefox from the commandline with the copied profile (e.g. firefox.exe -profile C:\users\myuser\profilecopy)

Am I missing something or is the profile handling code in firefox broken on windows 10? I tested a build from last November with mozregression, same issue (builds from a year ago just crash, apparently).
Flags: needinfo?(wlachance) → needinfo?(jaws)
Confirmed through IRC that -P is used on Windows instead of -p.
Flags: needinfo?(jaws)
Actually I think it's --profile that's the magic option that seems to work. Need to do more digging about this (mozrunner, which mozregression relies on, uses -profile). It looks like some stuff around this changed in bug 1080302, though I don't think breaking -profile was intended (if it even happened there).

I will do some more investigation on this Monday. The simplest thing might be to just use --profile and live with the profile option not working on old versions of Firefox.
We should possibly also update this page:

https://developer.mozilla.org/en-US/docs/Mozilla/Command_Line_Options
Spent some more time debugging this on my Win10 VM with no luck getting it to use the correct profile. I have no idea what's going on. All variants of -p, -profile, and --profile work fine on my Windows 7 VM, so I'm now unconvinced that the bug is in mozrunner. Not sure how to debug this in more depth without installing a full Windows dev stack and compiling a custom build of Firefox (I'd really rather not go there).
You need to log in before you can comment on or make changes to this bug.