Firefox 67, multiple user profiles, FF 66 behaviour required

[katoda]

Basically, on my machine Firefox is set a a default browser and I have two user profiles.

Golden rule of running two of more Firefox versions is never to have any set as the default browser!

I do not have two Firefox versions on my machine, I have one Firefox installation (currently v67, updated yesterday) and two profiles, which is perfectly correct and supported by the software. In such case there is no issue with having Firefox set as default browser.

[kerft]

Major problems occur when you run a profile with the version you do not intend to run it with. Even a very minor case like using beta of only one version ahead to run your current profile, will set a flag in the profile so it will not run with the release version unless you override it.

If you only have one version, the worst you could do is open a tab in the wrong profile, or restore a session at a time when you didn't want it to show up, or lose a session by closing it while another window belonging to the same profile was open and unnoticed.

[willi uebelherr]

Dear katoda,
i think, the answers are not really helpful. I have the same problem now after an update from FF66 to FF67, but in another configuration. I use a static FF67 and portable FF67. The portable has principally his own profile.

Normally, before, always the running FF version was used, if i activate a link (email). Now, if the portable version is running, a new FF-instance (the static, default) is started.

I was very happy to find your request. Maybe, you find a way to continue with the FF66 behavior. Then, please, let us know.

greetings, willi
Asuncion, Paraguay

[Brummelchen]

SeaMonkey does not look to do that.
FF 56 does not do that.
FF 66 does not do that.


So FF 67 is silently adding a -no-remote switch.

firefox behave as expected, there is nothing wrong. if an instance has not -no-remote switch it will switch to the current and first and only running firefox.

but what you have noted

Uses a different profile

if firefox is regularly installed and has full control of its profiles then it will switch automatically to a separate profile. this feature was announced:
https://blog.nightly.mozilla.org/2019/0 ... hitecture/

-no-remote is still needed.

if firefox finds a manually created profiles.ini without installs.ini it will behave as ever.

[therube]

firefox behave as expected, there is nothing wrong.

No, FF is not behaving as expected, there is something wrong.
Mozilla broke expected, existing behavior & said nothing of it.
(Whatever may have been "said" is essentially meaningless.)

if an instance has not -noremote switch it will switch to the current and first and only running firefox.

Don't know what FF will do, except something not expected.
Until someone, you, I... sits down & gets a good understanding of how things now work, & how users need to adapt to this "new", "better" FF, about all that can be said, is it does not work.

Forget the "installed" part.
"Installed" has nothing to do with it. The same way that "addons" are a misnomer.

Nightly, beta, release, or whatever, also matters not.
All one needs to have is "FF", be it multiple versions, be it a single release version, >= 67.

if firefox finds a manually created profiles.ini without installs.ini it will behave as ever.

Then how did installs.ini end up being created on my end?
I have always had a profiles.ini.
(I may not be reading correctly what you're trying to get across.)
All FF users (well not really, but...) have profiles.ini.
That "blog" post is drivel (as are most everything that comes out of Mozilla's mouth).
Nowhere there, or even anywhere else that I have found, gives a clear understanding of how this "new" FF works, to the point where a user, you, I, or joe or katoda or willi know how to proceed at this point.
Knowledge is so lacking, that (as of yesterday) a google search for "firefox installs.ini" suggested something different, & you had to specifically tell it to search for "firefox installs.ini".

[therube]

Major problems occur when you run a profile with the version you do not intend to run it with.

Potentially, or even very possibly, but so what.
If one is going to use multiple Profiles, or multiple instances, or multiple versions, then one is expected to know how to do that without issue, & to know ahead of time expected consequences.

Even a very minor case like using beta of only one version ahead to run your current profile, will set a flag in the profile so it will not run with the release version unless you override it.

If one is running > Release, I'd expect them to know the consequences of doing so, & how to do so safely.
Likewise, if one wants to run blabla version on albalb profile & then do something "bad" by running a different wawawa on that same profile, do they really need hand-holding from Mozilla. If things are that difficult, that bad, then let them keep their betas & nightlies inhouse only & only release Releases.

If you only have one version, the worst you could do is open a tab in the wrong profile

What Profile is one expected a tab will open into? Or is that even known, or expected?
Before 67 it was. Now... ?

or restore a session at a time when you didn't want it to show up

I had that very thing happen the first time I ran 67.

or lose a session by closing it while another window belonging to the same profile was open and unnoticed.

Not quite what you mean there, but if I'm reading your comment correctly, there has been no change in that regard.
(Ctrl+Shift+T & Ctrl+Shift+N still exist.)

[willi uebelherr]

Dear kerft and Brummelchen (german?),

you have first to accept the reality. katoda wrote:
"Basically, on my machine Firefox is set a a default browser and I have two user profiles. One is set as default, another one, for which I have a separate Firefox shortcut, is launched by using Firefox's -P parameter. It worked perfectly: If there were no Firefox running and e.g. a link in the Word document was clicked, then a new Firefox windows with default profile is launched - as expected. But If I already had running Firefox with second profile, then there were no new instance launched, just a new tab in the current opened Firefox windows was created."

I explained, that i use always two FFxx with the same versions static and portable with always his own profile. Two very different methods, but the same results.

And now, how therube explain, we need the support about, what we have to do to continue our working methods. I myself worked many years on that way without to have to change my working style. Only to switch over some 0,1 subversions. Mostly after then the big errors was corrected. I got this information also here.

Maybe, you have the connection to the moz-dev-groups, Please ask this friends, how we can bypass this wrong doing. Or, if it is well constructed, what we can do to go around.

It is not the task of every user to go deep inside. There are many people they have this experience and knowledge.

many greetings, willi (german)

[katoda]

To all: I reported this behaviour a a bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1553815 - feel free to comment and vote, if you find the current behaviour erroneous.

[Brummelchen]

read bugzilla

This is the intentional behaviour since Firefox 67. If you want to open a new tab in an existing instance of Firefox you must launch Firefox in a way that targets the profile for that instance.

i was not conscious about but i would say that sounds logical. ofc it is different because firefox did jump into current session when started twice, (no matter which one, it transfers the command to current session)

that far i dont have a default profile - firefox need to ask which one it can use.

[therube]

you must launch Firefox in a way that targets the profile for that instance

Not only do they not document this change, he can't be bothered to give any clue as to how to accomplish that. (As far as I'm concerned, his response is RESOLVED INVALID.)

So does the -instance switch work?
Does the -instance switch even exist any more?

Would some (Windows) Registration entry need to be modified such that an "external" link, DDE kind of thing, which has always "worked" in earlier FF, will now need to be modified to accomplish what it did before for this new FF 67?

If FF 67 opens multiple, who knows what they are doing ?, but as seemingly -no-remote may be involved, if -instance is still a valid switch, can you now -instance to a (potentially) -no-remote'd instance (which was not possible before)?

[katoda]

Yep, they claimed that such behaviour is now intentional and at the same time it invalidates the entire idea of having profiles in Firefox. Why the hell I should have different profiles per user if I cannot control which profile is used while another process is launching Firefox.
Honestly, I'm really bummed by it. It makes part of how I use Firefox simply nonsense, as I frequently launch Firefox from another applications as the default system web browser and now either each time I must decide which profile to use or I will land with a profile which is not mine, does not have my passwords, bookmarks etc. Ridiculous.

[therube]

Release notes:

Users will be able to run different Firefox installs side by side by default so that you can run the beta and release versions simultaneously

Now, "users". "Users, we've already learned, are dumb. Now why would they want to allow a (dumb) user to "run different FF installs" [whatever that means?] "side by side"?

And in the next breath:

Its use is to give any given Firefox install a distinct icon. One may do this for cosmetic reasons alone, but a more practical use is when running multiple instances of Firefox when one's Windows taskbar buttons are not set to "combine". Normally this will result in a row of Firefox taskbar buttons that all look the same (especially problematic when new windows are used with the various instances). The removed icon feature was the longstanding workaround for that problem.

(Note he mentioned, "instances".)

And the reply:

a more practical use is when running multiple instances of Firefox

So what's the use case for this?

So we have a "user" wanting to use a feature, multiple instances (& a way to visually differentiate these multiple instances) & we have FF (67) that lists as one of its' features, the ability to "run different installs" (whatever an "install" is supposed to mean, but lets just call it an, "instance", for the sake of argument), & a Mozilla employee who gives the impression that a "user" should not be running multiple "instances". (Well, perhaps unless it happens to be a Release "instance" & a "Nightly" instance, in which case, that's OK. But by the same token, haven't we already decided that "users" should not be allowed to run Nightly, being dumb & all that?)

[mightyglydd]

What about 'Cult' and 'Control' don't you understand?
I assume you're aware that the the ability to disable multi-process is next on the chopping block.

[therube]

(And icons & css & updates [& users]. But we all knew that.)

[therube]

you must launch Firefox in a way that targets the profile for that instance

he can't be bothered to give any clue as to how to accomplish that.

I can tell you what not to try .
(Both "instances", Profiles, ff61 & profile67 are up & running.

Code: Select all

E:\Users\RUBEN>C:\WLIB\FIREFOX\FIREFOX\firefox.exe -instance ff61
E:\Users\RUBEN>C:\WLIB\FIREFOX\FIREFOX\firefox.exe -instance ff61 -no-remote
E:\Users\RUBEN>C:\WLIB\FIREFOX\FIREFOX\firefox.exe -instance profile67
E:\Users\RUBEN>C:\WLIB\FIREFOX\FIREFOX\firefox.exe -instance profile67 -no-remote

The second opened "instance", ff61, shows it is opened using the -no-remote switch, though that switch was not specifically <<---that's wrong

^---that's wrong
i forgot i manually added the -no-remote switch to my desktop shortcut - thinking it was required - prior to knowing about any of this, so... let me see...

first instance, opened from desktop shortcut, which calls Profile Manager -> profile67... firefox.exe -P
second instance, opened from opened from desktop shortcut, which calls Profile Manager -> ff61... firefox.exe -P

Neither show that they are using the -no-remote switch, though the second opened instance, ff61, must "be" using -no-remote (or whatever trickery Mozilla has thrown in here [check for a process named "firefox.exe", if exist, do... ?]). In any case, I did not specifically tell FF to use -no-remote, I simply said, open a specific Profile, ff61.

Now, -instance seems to have no affect.
> E:\Users\RUBEN>C:\WLIB\FIREFOX\FIREFOX\firefox.exe -instance ff61 www.google.com
> E:\Users\RUBEN>C:\WLIB\FIREFOX\FIREFOX\firefox.exe -instance profile67 http://www.google.com
Google.com is opened in ff61 Profile, regardless.

Why ff61 Profile was chosen instead of the first opened profile, profile67, you've got me?

And -no-remote switch doesn't help any. All that happens with that is that Profile Manager opens (& http://www.google.com is not loaded, anywhere).
> E:\Users\RUBEN>C:\WLIB\FIREFOX\FIREFOX\firefox.exe -instance ff61 -no-remote
> E:\Users\RUBEN>C:\WLIB\FIREFOX\FIREFOX\firefox.exe -instance profile67 -no-remote


So...

you must launch Firefox in a way that targets the profile for that instance

Clear to me, isn't it.

Code: Select all

Usage: C:\WLIB\FIREFOX\FIREFOX\firefox.exe [ options ... ] [URL]
       where options include:

  -h or --help       Print this message.
  -v or --version    Print Firefox version.
  -P <profile>       Start with <profile>.
  --profile <path>   Start with profile at <path>.
  --migration        Start with migration wizard.
  --ProfileManager   Start with ProfileManager.
  --no-remote        Do not accept or send remote commands; implies
                     --new-instance.
  --new-instance     Open new instance, not a new window in running instance.
  --UILocale <locale> Start with <locale> resources as UI Locale.
  --safe-mode        Disables extensions and themes for this session.
  --allow-downgrade  Allows downgrading a profile.
  -MOZ_LOG=<modules> Treated as MOZ_LOG=<modules> environment variable, overrides it.
  -MOZ_LOG_FILE=<file> Treated as MOZ_LOG_FILE=<file> environment variable, overrides it.
                     If MOZ_LOG_FILE is not specified as an argument or as an environment variable,
                     logging will be written to stdout.
  --console          Start Firefox with a debugging console.
  --headless         Run without a GUI.
  --save-recordings  Save recordings for all content processes to a directory.
  --browser          Open a browser window.
  --new-window <url> Open <url> in a new window.
  --new-tab <url>    Open <url> in a new tab.
  --private-window <url> Open <url> in a new private window.
  --preferences      Open Options dialog.
  --screenshot [<path>] Save screenshot to <path> or in working directory.
  --window-size width[,height] Width and optionally height of screenshot.
  --search <term>    Search <term> with your default search engine.
  --setDefaultBrowser Set this app as the default browser.
  --jsconsole        Open the Browser Console.
  --jsdebugger       Open the Browser Toolbox.
  --wait-for-jsdebugger Spin event loop until JS debugger connects.
                     Enables debugging (some) application startup code paths.
                     Only has an effect when `--jsdebugger` is also supplied.
  --devtools         Open DevTools on initial load.
  --start-debugger-server [ws:][ <port> | <path> ] Start the debugger server on
                     a TCP port or Unix domain socket path. Defaults to TCP port
                     6000. Use WebSocket protocol if ws: prefix is specified.
  --recording <file> Record drawing for a given URL.
  --recording-output <file> Specify destination file for a drawing recording.

And not this either (also causes Profile Manager to open):
> E:\Users\RUBEN>C:\WLIB\FIREFOX\FIREFOX\firefox.exe -p ff61 http://www.google.com
> E:\Users\RUBEN>C:\WLIB\FIREFOX\FIREFOX\firefox.exe -p profile67 http://www.google.com


Oh, I've got it now, we "must launch Firefox in a way that targets the profile for that instance".