Firefox 67, multiple user profiles, FF 66 behaviour required

[willi uebelherr]

Dear therube, you wrote:
"You can no longer rely on "documentation" or even your own pre-existing knowledge to know what to do - because FF 67 change what & how things work."

I think, this is not true. What i see is, FF67 follow very strong this definition. FF version and profile is now a unit. The problems comes with the implementation and bad documentation.

@Brummelchen told it a strong logic. I think now the same. And katoda also.

The consequence for me. The basic installation on a system have to be the actual version. Any link use this, normally, if we don't have more then one entries in the browser reference list. In Windows in the registry.

This default instance have to follow the basic logic. For the system, his task is finished. It give the control to firefox. Firefox itself have to organise his own application rules. Never the system.

With that we come to the profile.ini file. This is the instance between system and target FF instance, combined with .exe-file and profile directory.

Before, i never used the installed profile.ini-file. T.Hager in the portable forum wrote about tools to setup the profile.ini-file. Some people propose .bat-files.

Katoda use shortcuts for different versions and their profile.

I only work with portable. It is not the "mass" how Brummelchen wrote. It is very specific. I will follow very strong this logic. I hope, my interpretation is correct. You can help me to find errors. Katoda wrote, he will do the same, that all of us "are happy". Many thanks to him.

I will write, after waiting your answers, in bugzilla.mozilla this interpretation. There are 21 people with a high inside knowledge. Maybe, they can help us to find a stable basic thinking. And i will ask T.Hager, to visit us here in the MozillaZine forum.

[therube]

I'm all for logic. But there is no logic, that I have found, in this.

From prior to FF 1.0 through FF 66.0, there was logic & consistency, & everything worked, logically, consistently as expected.
Now there may have been features or whatever that people may have wanted, that did not work, but that's an entirely different issue.

Fact is, that with FF 67 all logic is out the door.


In the day, there was this "thing", named "IBM".
And their "mantra" was our way or the highway.
They controlled everything. If you wanted to do it, you did it their way.
And they had volumes of documentation of what there way was.

On Mozilla's "mantra" list is, "openness" (lol).
We can't even get cursory information as to what Mozilla's way is?
(Well, I guess once they figure that out... it will be too late, if it isn't already.)

[therube]

So using your logic, tell me why "firefox.exe -p ff61" did not open the profile, ff61, instead opened a new profile in some rather arbitrary location - that is not even in profiles.ini (or at least certainly not put there by me) [Guess I should have a look at "installs.ini" too]?

That is all I ask for, for some logic be brought to the situation.
For someone tell me what I should be expecting & just how to accomplish what I need done - because I no longer know?



Oh, wait, I forgot that I did add that location through Profile Manager, hence it does exist in profiles.ini.
Nonetheless, what did occur should not have, or at least based on any logic I can figure.

Code: Select all

[InstallD5D75249A5454E275]
Default=C:\WLIB\Mozilla\USERS\FF61
Locked=1

[Profile2]
Name=FF61
IsRelative=0
Path=C:\WLIB\Mozilla\USERS\FF61
Default=1

[Profile1]
Name=FF59
IsRelative=0
Path=C:\WLIB\Mozilla\USERS\FF59

[Install8A92B18FED63327C]
Default=C:\TMP\SEA\52.9\PROFILE67
Locked=1

[Profile0]
Name=FF58
IsRelative=0
Path=C:\WLIB\Mozilla\USERS\FF58

[General]
StartWithLastProfile=0
Version=2

[Profile3]
Name=PROFILE67
IsRelative=0
Path=C:\TMP\SEA\52.9\PROFILE67

[Profile4]
Name=fmozilla {expletive changed because this is a family forum}
IsRelative=0
Path=C:\TMP\SEA\52.9\newtext

I have only ever had the first 3 profiles (declared in profiles.ini).
The other two are only since FF 67.
FF61 is my "default" (whatever "default" is supposed to infer?).
Except for the fact that on my very first open of FF 67, it did not open my "default" profile, FF61, I may not have ever run into all of this. (Actually, I'm almost certain that I would have , just it would have take a little bit longer.)

[willi uebelherr]

Dear therube, i understand very good your frustration, because we all feel the same. Years over years we develope and use our working method, and now, suddenly, it is breaked. The consequence is, we need a new common sense, that we can act in different environments based on the same principles.

I am not shure, that i understand it correctly. For this, i act in this really very constructive forum. Now, i copied my comments from here to the portableapps forum. There are many people with deep experience, but oriented to the portable version.

I think, together we can find the basic principles and can search the implementations for different environment. It have to be simple and useful. The result should be, that "all are happy" (katoda).

"tell me why "firefox.exe -p ff61" did not open the profile, ff61, instead open a new profile in some rather arbitrary location"

This your question is very important. But we can find only then a correct answer, if we have clear the basic rules and his implementation. Maybe, this are not completely compatible to the FF67 rules. Or your configuration is not compatible. I don't know. For myself, i need a stable orientation to go to a specific implementation.

I hope, we will find it and then we can find good and stable solutions for different environments.

[willi uebelherr]

Dear therube, i am not experienced with the profiles.ini-file. But for me it is clear, the FF67 have to be the default under all circumstance, because only this version follow the new logic rules, what are in reality the old logic rules, but not consequent implemented.

And this default FF67 version have to organise the correct target version and profile. And if this selected target is running then it open a new tab.

I hope, that this logic is the correct one.

[jscher2000]

So using your logic, tell me why "firefox.exe -p ff61" did not open the profile, ff61, instead opened a new profile in some rather arbitrary location - that is not even in profiles.ini (or at least certainly not put there by me)

My shortcut I've used since Firefox 57 works for me in Firefox 67 on Windows 10. It has this "target":

"C:\Program Files\Mozilla Firefox\firefox.exe" -P "Quantum"

It works even if a different profile is listed as default in installs.ini/Profiles.ini.

So I think at least that part *should* work. Not sure why it isn't working on yours.

More on my setup, if relevant, was here: https://bugzilla.mozilla.org/show_bug.cgi?id=1553815#c9

[willi uebelherr]

Dear friends, this i wrote in bugzilla.mozilla thread.

"Dear friends, i have a question about "launch Firefox"

The way for external start request is?

The system (windows or other) give the control to the default system firefox
This firefox use the profiles.ini to select the firefox profile (default or parameter defined)
This firefox give the control to this targeted instance (itself or another (running or new started))

Inside of the running firefox it is different. It stays there.

For an answer i would be very thankful."

Now, i welcome jscher2000, also in bugzilla activ, in our discussion. If this rules, what i have explained, are correct, then we have to concentrate to the profiles.ini-file in the system default FF environment. And clear, this has to be FF67++.

Start FF with parameter -P is normally working. Katoda explain the same. I myself never used it.

[dickvl]

If you have a problem with using a specific profile then try to delete compatibility.ini in this profile. See about:profiles for a button to go to its root location.

[willi uebelherr]

Dear friends,
in my specific environment, FF67 static and portable installed, every instance with one profile, i found the solution with registerfp.
https://www.winhelponline.com/blog/regi ... -in-vista/

This information i got from PortableApps forum:
https://portableapps.com/node/60315

With this tool i registered the portable version and with the win "defult program" i can change the default FF path. This works in all tested conditions, what i have. It is an old tool, only for portable FF. But i know, that the developer of PortableApps will include this function in a more general stile.

In the bugzilla thread Dave Townsend gave the link to 1554577.
https://bugzilla.mozilla.org/show_bug.cgi?id=1553815

"Actual results:
Firefox will now open the link in the default profile and if you have a custom profile loaded through the commandline it will be ignored. All shortcuts and saved settings will use the default profile instead of the one you already have opened."

In my situation, i use two FF67 registered installation and switch between. In your situation like katoda, with different versions and maybe different profiles for one version, you can manage the profile.ini-file, because the executable file is also included in the profile (pref.js?).

It would be more elegant to find the same method for static and portable installations. For the portable instance under Windows, the drive path can also change. But this is a task for the portableapps launcher.

But in general, a user defined switch should installed, that the running FF-instance is now the default. In all our disussions we see, we, the user, have to follow only the view of the developers. But this is not a good way and make every time problems with new logic definitions or consequent implementations of the old definition.

with thanks for all and many greetings, willi
Asuncion, Paraguay

[therube]

Isn't this just MS-like, throw out "features", with no clue & get feedback from end users.
Would someone remind me just what was accomplished by this "feature"?

Bug 1555319 The case insensitive file system on Windows makes it possible to run Firefox with seemingly different installation paths

Bug 1543414 [Dedicated Profiles]Two separate installs are using the same dedicated profile when forced by profile manager

Bug 1553929 If a profile's path in profiles.ini doesn't match the expected serialisation then finding and setting the default profile is broken.

Bug 382477 -no-remote interferes with other Gecko based applications (e.g. Firefox launching Thunderbird via mailto or TB launching FF via click on link)

Bug 1553554 Firefox 67 thinks it's an old version and won't load my profile

Bug 1554252 Firefox doesn't start if installs.ini or profiles.ini attribute is set to read-only
(I can certainly see one's desire to set profiles.ini to read-only. In my case, I simply make a backup copy of profiles.ini, & that suffices for my needs.)

Bug 1555134 Clicking on a link in an application running elevated will open a new Firefox window
(This is the "sensitivity" issue hitting.)

Bug 1528082 Add an environment variable to disable dedicated profiles

Bug 1553604 New Profile System Problematic On Linux Servers
(Mac specific, or so it would seem, yet the bug doesn't actually indicate that.)

I understand bugs (in that bugs happen).
I can accept bugs.
But this (& not because of these few bugs) I cannot accept.
That they implement behaviors - for who knows what reasons, that easily break long (from day 1) established usages.
(Some of the lyrics of the song that I happen to have playing - just now - I don't know why, I don't know why, I don't know why .
Song, The Weepies - Takes So Long .)

[willi uebelherr]

Dear therube, thank you for your long list of bugs, not or wrong implemented logic, what is declared. I don't understand the developer group and her thinking space. Maybe, the left hand don't know, what the right hand do and reverse.

A typical example of unlogical speaking is to start a profile. Many time i have read this nonsense. But never you can start a profile, only the executable FF instance with a specific profile.

In your list we see many curious things. It comes, if the developers have no clear view of, what they have done themselves or others. There is no clear orientation and big ignorance and arrogamce. With this last behaviour you will never lern from the users.

[mightyglydd]

"You will be assimilated; resistance is futile."

[Brummelchen]

This information i got from PortableApps forum:

this is not new, its well (ever) known to make the portable starter as default "browser" and not to use the option within firefox which do not imply the path to profile. but this is only a workaround because the portable was never intended to run as default browser.

for "RegisterFirefoxPortable.exe" it needs NET Framework 3.5, for those who are on windows 10, maybe windows 8 affected too. that tool is no option here as i dont see any benefit of using such old software which needs still dotNET 3.5.
the possible interference with that tool and portable starter could be, that the portable starter adds -no-remote under cirumstances and this has to be avoided if possible in options.

from the bugzilla reports - seems not thought until the bitter end. mozilla need now to deal with various problems that the mass of user wont have. in special 1555319 is user made problem. yes, windows insesitive, but Windows dont own c:\program files\, its anytime "C:\Program Files" - and the template folder from installier is anytime "Mozilla Firefox" and not "mozilla firefox".

and for 1553604 - well admins using the regular build (not ESR) are in charge to try the beta (or nightly) out to track changes. its stupid not to do and now he has trouble.

[willi uebelherr]

Dear Brummelchen, what you propose now?

I have read in the portable forum they are working for that. Maybe also for thunderbird or other application. In the registration, i don't find anything like "no-remote". i have to look, what this option tell us.

With the FF67, my working with firefoz portable was impossible. If i activate a link with htm(l), the default system FF67 was startet. Now, i have the old FF66 behaviour, the same, what we find in the title of this thread. And now, you think, it is bad? No, it is very good. And any time, John Haller from PortableApps will explain us the new mechanics, then, too, we work in the same FF66 behaviour. I love that.

The question for katoda and therube is different. I hope, they find a good way to continue his working method in the old FF66 style.

I know, in reality, the logic for firefox is not changed from 66 to 67. Only the implementation changed.

[Brummelchen]

John explained nothing, he (*correction) just wrote that anything works as expected and we already here got that point before. what you have is a work around for you - and only you. it wont be applicable for my needs, not a second.

if firefox sticks with exactly one installation and one profile - or one portable - anything is fine to make something as default browser with default profile. if you have more then one of those there wont be a general solution, some has to decide whats his default browser. you cant use an installed firefox as default with a portable as default, that is not possible with out tricks never were written down here. it is complicated. and it gets more complicated if you are on a host system without rights (thats what portable were intended for)

what i can tell you that the starter from portable apps is limited for multiprocess. it is not capable to find all instances and within its own portable. and it contains a lot of outdated and not needed code. firefox is really able to run portable without this amount of changes of files in profile.
no matter it works because script can not work on files which are not existent, but in general it has no benefit.