Closed Bug 221167 Opened 22 years ago Closed 21 years ago

firebird does not respect profile switch if instance already running

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: alvin, Assigned: bugzilla)

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031002 Firebird/0.7+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031002 Firebird/0.7+ steps to reproduce: 1. create multiple profiles 2. launch Firebird with one profile MozillaFirebird -p profile1 3! launch Firebird with second profile MozillaFirebird -p profile2 expected behavior: firebird should open new window with settings from profile2. actual behavior: firebird opens new window with settings from profile1 in the mean time (before this is fixed), is there any way to force a new instance of firebird in windows so i can start w/ second profile? thanks, alvin Reproducible: Always Steps to Reproduce:
hello? anybody home?
hmm... the person to whom this bug is assigned is excluded from getting emails for it...
this sounds like it would depend on the ability to run multiple instances (separate processes, not new windows). and as far as i know, you can't normally run separate instances. i searched, but couldn't find a bug for that. might also be related to profile switching in firebird, which i could find no relevant bugs for either. tho not by default, it is possible to run multiple instances with different profiles thru use of seperate installations, startup scripts, etc. search http://forums.mozillazine.org/ for more info on that. oh yeah... i can confirm this on windows 2000 with 0.6.1.
I can confirm this on windows XP and Windows 2000. Build: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8 Even if I use a different build from a different location the browser uses the previously installed browser's profile manager.
as i said earlier, the person to whom this bug is assigned does not get emails for this bug. in addition, there is no response to emails sent directly to the email address. since this bug seems to belong to someone who doesn't exist, and since for some reason i've lost submitter rights to it, i'm reopening. this bug has been in limbo long enough. in addition, the problem exists on all OSs.
Severity: normal → blocker
OS: Windows XP → All
WFM with Firefox 0.8, try a newer build? Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8
i'm using 0.9 and, while it's better, it still doesn't work properly. if you add this step: 4! launch Firebird with first profile again MozillaFirebird -p profile1 <URL> it will load the page in the profile2 window. this is more of a feature request, but the browser would be much more powerful if you could control to which window a URL was sent based on the profile switch. that way, you could have (for example) a 'help' profile that apps could use to show help without all the toolbars. or perhaps have certain apps create a new window while other apps reuse the default one.
do you have the MOZ_NO_REMOTE=1 environment variable set under Windows? If not, by design any attempt to open another instance gets detected and a new window is opened. If you want to run multiple instances with different profiles, set that environment variable in Windows and go nuts. Linux and other platforms need to use a startup script, which is why it works on Linux just fine. You could file an enhancement request to make the profile switch override the code that does this, I'm not sure whether anyone really wants to work on that type of thing, considering there is a very simple workaround for those people who would actually prefer this behaviour. (If you question whether people prefer it, look at the number of bugs/posts on the forums about NOT having this behaviour by default on Linux). About the delay, sometimes it happens. The General component gets a massive amount of bugs, many that don't belong to Firefox at all. Even working fast, to properly triage bugs I manage about 10 bugs an hour. I put a lot of time into this project, unpaid, and I don't believe you really have the right to judge people for missing one bug out of hundreds. This isn't a blocker, either.
Severity: blocker → normal
QA Contact: mconnor
i'm using fc1 linux with the startup script, and it doesn't work (as described above).
i(In reply to comment #8) > About the delay, sometimes it happens. The General component gets a massive > amount of bugs, many that don't belong to Firefox at all. Even working fast, > to properly triage bugs I manage about 10 bugs an hour. I put a lot of time > into this project, unpaid, and I don't believe you really have the right to > judge people for missing one bug out of hundreds. > > This isn't a blocker, either. my problem isn't in the delay itself, it's his attitude on the other bug report, as if it were somehow *my* fault. i have no idea your mechanism for assigning bugs, but after 5 months with the appearance that no one had received notification of the bug (apparently he was deliberately ignoring it), i thought it reasonable to submit a new report.
(In reply to comment #9) > i'm using fc1 linux with the startup script, and it doesn't work (as described > above). For Linux you have to use following: http://www.mozilla.org/unix/remote.html
re: comment 11: i don't have a problem opening new/multiple windows. the problem is that it doesn't respect the profile switch when doing so.
wait, which startup script? if you're using a startup script that launches new windows correctly, that script could be overriding the profile switch, since I don't think you can combine the profile and remote switches
if you follows steps 1-3 (and 4 from comment 7 on linux) you will see what the problem is.
after setting MOZ_NO_REMOTE=1 as an environment variable under Windows 2000, I can open multiple profiles using the -p switch as desired. under Linux (FC2 test1 and SuSE 8.2 tested) I do not use a startup script and I am able to successfully invoke multiple profiles via Profile Manager or by using the -p switch. Using a startup script that utilizes -remote on Linux behaves exactly the same as the default behaviour on Windows. In both cases, the profile switch is ignored deliberately as the main point of having such behaviour is to allow links opened remotely to open in the same profile.
again, please read comment 7. the point is you *should* be able to redirect the URL to be opened in one profile or another based on the profile switch. as i said in comment 7, you could have (for example) a 'help' profile that apps could use to show 'popup' help content without all the toolbars, and a default 'open web URL' profile with toolbars. the point is that if you wanted it, apps could use different profiles (read windows/styles) to show content, based on what is being shown. i understand that this is more of an enhancement now that the behavior has changed, but i think it would be a really useful enhancement. i also mentioned this in comment 7.
comment 7 also stated that you're using 0.9, after that I admittedly didn't read carefully. Here is why this bug will most likely never be fixed: 1) -p isn't designed to work with existing processes. Period. It would need to be able to discover if ANY of the open processes for that user are using that profile, in which case it would have to open the link in a new window (DDexec is inconsistent enough already, without trying to add this particular case). If, and only if, the process in question isn't running, it needs to continue launching. This would probably require rewriting largish chunks of code that simply detect a running instance and feed the URL to that instance (which is currently only done on Win32/OS X, *nix builds use startup scripts) to actually be much more selective and advanced. 2) To make this work on Linux, we would need to rewrite how -remote works as well, since -remote finds a running process and opens the link in that. -remote would also need to be rewritten to handle this case. I don't know if this can be done without breaking long-establish usage of -remote. 3) This is behaviour that is off by default on two of three primary platforms, and I anticipate 1.0 will ship on Linux with a startup script that adds the same functionality (unless someone makes this work like win32 on linux, which is planned at some point). So we have to justify the work involved (make no mistake, its substantial) in the light of this being something that is obscure to begin with. 4) This caters to no one but the power user, and even mostly the advanced power user. Such a functionality isn't needed or desired in Firebird, especially with the amount of code that would go into supporting this properly.
i'm not so sure it would be such a major undertaking; i (and others) have written shell scripts which handle much of the needed functionality. you can already open the browser multiple times, each with a different profile. a script can determine which profiles are currently in use by using a lock file or other means. i believe the software already supplies the window handle of the new window, so the only thing that needs to be supplied by browser code is a way to map the profile name to its handle, a trivial undertaking. alternatively, if you could supply a way to open a URL in a specific window by supplying its handle, the rest could be done with a shell script. i could supply the script if you could do that.
Firefox does not expose Profiles or profile switching to the user and it's unlikely that this is going to change. Therefor, we're not going to spend time adding new profile-related features like this. Sorry. Feel free to work with extension developers if this is something that can be done as a 3rd party extension.
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.