Rename the executables according to their edition name

Firefox Development
,
1

I once submitted this issue by the Feedback prompt when uninstalling Firefox, but seems no one cared or simply didn’t read.

I use multiple web browsers, and while you can install all the editions in the computer, that doesn’t mean the OS sometimes makes any differentiation on which version is which, all due to every executable on each edition (except for Nightly IIRC) share the same naming “firefox.exe” the worst issues are among ESR, Standard, Beta & Unbranded, no different icon (except for Unbranded), same executable name & you can differentiate them sure if you read descriptions or make custom icons or shortcuts, but Windows doesn’t.

You may think that now this is a rant, but it isn’t, due to all being firefox.exe I cannot control individually their process priorities, affinities or CPU Sets, manually, because doing so for one, it does for all the others, just to give an example on the matter.

& it’s all due to not naming the ESR exectuable just that, here are some options: FirefoxESR.exe, FESR.exe | & please add a small legend to the default icon.

For Beta, here are your possible options: FirefoxBeta.exe, FirefoxB.exe, FBeta.exe | & please add a small legend to the default icon.

For Developer Edition; FirefoxDeveloperEdition.exe, FirefoxDeveloperE.exe, FirefoxDE.exe, FDE.exe

For Unbranded; FirefoxUnbranded.exe, FirefoxU.exe, FUnbranded.exe

Here’s a picture showing the issue where I set my affinities to ESR but are being duplicated to DE:

image
image398×273 7.47 KB

I really hope this doesn’t get ignored & gets addressed. It was due to this reason I wasn’t using Vainilla but some Fork & while that’s a choice, it’s something it didn’t have to take place at all.

2

Hi, could I ask how you are setting up these rules?

It looks like it might be “Process Lasso”. I’ve never used this tool, but from the docs it seems like you might be able to set things by matching the whole executable path, instead of just the process name (i.e. the executable file name).

3

Yes, Process Lasso is being used to retain the settings.
If you manually do so through the task manager, these modifications are never saved when you close the selected program.

Yes, using the whole path is a thing, but for some work I have to do for undisclosed reasons; when I try to run another instance under a portability workaround, the processes matches & these cannot run, quite opposite when these are installed by the traditional way, something that for undisclosed reasons most of the time I have to avoid while working.

I already tried to work with these portabilities manually changing the processes name but it simply refuses to recognise the new name by modifying the ini configuration & I properly contacted people behind some portable alternatives on this same matter just in case they can do something about it, but haven’t received a single response yet. So I just decided go to the root of the issue and well, here we are at.

I don’t really think I’m asking for something that is too much difficult to modify on the developer-end (if so, please let me know if possible), don’t get me wrong, as I indirectly stated before, I already had put my little effort to work with what I already have, but it is becoming too much hassle for something quite simple, a proper naming for the main executable based on the edition.

I provide an example while trying to run an alternative:

image
image398×311 9.03 KB

In the image it can be seen such error, this error is while trying to open Firefox Developer Edition by PortableApps, behind it can be seen I was already running one Firefox instance, ESR to be precise, so both of this processes are interfering with each other on this particular example.

4

Again I don’t know anything about the PortableApps distribution of Firefox, but that message might be because you are trying to run two instances of Firefox with the same profile.

If you call firefox.exe (or whatever you have renamed it to) with an argument of -P this should bring up the “Choose User Profile” dialog, where you can create new profiles (-P <profile name> will start with that profile directly). You can also use about:profiles in the browser to manage profiles.

I tried just copying the standard release Firefox directory and renaming firefox.exe, firefox.exe.sig and firefox.VisualElementsManifest.xml to firefoxRel.*.
This seemed to work. Obviously I’ve only done minimal testing and I can’t guarantee everything will work as expected.
I still think using the whole path for matching is your best option. Hopefully using different profiles will help.

I will raise the idea, but renaming the binaries for everyone could cause issues as well. For example other people will have rules set up like you that rely on the firefox.exe name. Also security software and even graphics drivers might have that name hard-coded.

5

I will take a look onto the profile arguments as you mention but yes, I’m glad you got a bit of interest on at least mentioning this idea so hopefully something can came out of of it eventually.