Status

()

The Mozilla Toolkit is a set of APIs, built on top of Gecko, which provide advanced services to XUL applications. These services include Profile Management, Chrome Registration, Browsing History, Extension and Theme Management, Application Update Service, and Safe Mode. (More info)

Security

(public)

User Story

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060814 Minefield/3.0a1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6
In Windows 2003, if a user is logged in and using Firefox, and another user logs in using Remote Desktop Connection using the same account, Firefox will not start and will show just the following error message:
Firefox is already running, but is not responding. To open a new window, you must first close existing Firefox process or restart your system.
This happens with all versions I have tested and as far as my programming experience tells me, it is caused by the method Firefox uses to detect multiple instances.
Reproducible: Always
Steps to Reproduce:
1. Log in Windows 2003 normally
2. Start Firefox
3. Using another computer, use Remote Desktop Connection (RDC)
to connect to the Windows 2003 system
4. Login using RDC with the same user name and password used at step 1
5. Start Firefox.
Actual Results:
Firefox quits with the following error message:
Firefox is already running, but is not responding. To open a new window, you must first close existing Firefox process or restart your system.
Expected Results:
Firefox should start normally.

create batch files :
set MOZ_NO_REMOTE=1
firefox -p session1
^z
set MOZ_NO_REMOTE=1
firefox -p session2
^z
ssave them as session1.bat and session2.bat in your firefox directory in program
files. create shortcut files to them and place them in your start menu.
what you expect is not practical. imagine both sessions opened bookmark menu and added different bookmark entries. what should happen?

Thank you for your reply.
While your solution may work (I did not have time to test it), I think we both agree it is not very practical.
There are plenty of cases where multiple users are logged in using the same user name and password, I will give just a few examples:
* job applicants connect to a server using RDC and start a custom application, fill a job interview or a form of some sort.
* employees working from home connect to a server using RDC and work on that computer (more and more used by companies that no longer allow people to take databases and critical information at home or on laptops)
* employess connect to a server using RDC a fill a time sheet at the end of the day
Therefore, in these cases, creating batch files is not a solution.
A possible solution to this problem may be storing an unique information along with the PID, such as -maybe - the timestamp of the last logon. A user connected through RDC would have a different last logon time.
As for the bookmark question, the first thing I think of is how are database applications where multiple users are working at the same time on a table work.
A very simple solution would be to create a flag, let's call him "bookmark_last_modified_time". When somewhere the bookmarks are modified, the variable is updated to the current time. If another session of Firefox has the Bookmarks window open and/or window receives focus OR when the Bookmarks menu is clicked, Firefox checks the variable and resyncs its view of the Bookmarks. Simple, reload bookmarks when needed.
In conclusion, I believe this "bug" should be considered and would be great to be fixed as probably a lot of people would be glad. However, if it would be to much work or it would mess compatibility with older versions, or for any other reason, I could very well live with Firefox as it is now.
I am a programmer but I am not a good enough programmer to work on Firefox, I would have offered myself otherwise.
(In reply to comment #1)
> create batch files :
>
> set MOZ_NO_REMOTE=1
> firefox -p session1
> ^z
>
> set MOZ_NO_REMOTE=1
> firefox -p session2
> ^z
>
> ssave them as session1.bat and session2.bat in your firefox directory in
> program
> files. create shortcut files to them and place them in your start menu.
>
> what you expect is not practical. imagine both sessions opened bookmark menu
> and added different bookmark entries. what should happen?
>

forget it. we're not letting you drive feature work.
yes bookmarks should eventually work like that, they did in netscape 4. but there's no way the firefox team is going to choose to work on this bug to fix it. in fact the database they chose was chosen with intent to have a single thread in a single process have exclusive access for performance reasons so that it wouldn't have to actually maintain coherency until it quit.
there's nothing preventing you from writing a very very complicated batch file, or a program, either way you can adapt what you now know to make yourself happy.
technically this behavior is as designed, this is not a bug, it's invalid.
your rdc examples are really messed up.
for one, you really don't want your employees to have access to web browsers if you're really afraid about *anything* especially security.
for another, it's not hard at all to configure multiple user accounts unless you're intentionally trying to violate microsoft's licensing arrangements, if you're doing that, well ... we're really not going to support you just so you can do that.
if you're actually remotely concerned about security, you should be worried about privacy and don't want one user to have access to another user's bits unintentionally. it's a huge security hole. user 1 gets infected and all other users logged in with the same credentials are suddenly infected.

This isn't as strange an issue as you seem to think. For instance if i login to my domain account, move to a separate pc and login again I can't use Firefox on the second computer.
This might be a design feature but if so its not the best feature.
It is odd from this point of view to think that Firefox needs to lock profiles for the entire session and not just as changes are made. This seems like a good way to make sure that if it crashes it will corrupt stuff or at least leave a lock file in place.
I've had numerous issues with this and can't manage to use a kiosk like mode for Firefox in our call center so that they all share one profile, one set of bookmarks, and one home folder.
The responses here were also harsher than I'd expected to see and quite rude in some cases. I understand that you do a thankless job and I can feel for you, but abusing those users who try to help make a better product (thats what bug requests are, not complaints, but requests to help improve a product) is being ungrateful in your own way.
Just my two cents on a fairly old bug, I've heard rumors that some of this is resolved in 2.0 but I haven't been able to confirm that in documentation or testing yet.

we have not been rude to you.
you have ignored all of our explanations.
i am well aware of how terminal services work. i have used them since 1999 (with Netscape 4 and Mozilla).
you are *not* trying to make the product better.
it's really quite trivial to make a login script that creates a copy of a read-only profile.
please don't comment in bugs about rumors you think you've heard. if you're going to hear or trust a rumor, test it first (you'd find out that it's absolutely not the case. profile locking exists, and existed in Netscape 4.)
we do not claim it's the best feature. it's a known and documented feature. the code is supposed to recognize when a profile is locked by a dead process and clear the lock.
we're not idiots. you may be stubborn, but we're not entirely incompetent.
and again, bugzilla is not for users to make feature requests. if you have a crash, you're free to report a bug. we do not deal with users here. the mere act of reporting a bug means you are no longer a simple user.

Status: RESOLVED → VERIFIED

Summary: will not start when two users logged in with same account (credentials) → will not start when two users logged in with same windows profile

I am using firefox on Redhat for my laptop. when my laptop is docked I have multiple desktops running; currently I can only open firefox on one of the desktops and the other will tell me that firefox is already currently running. Is there an easy fix for this? I hate having to use Konqueror in one window and Firefox in another.

I do not agree with people saying this isn't a bug. I will present another scenario.
I'm a Windows 2003 administrator, and logged with with domain\administrator at the console in the server room. I have firefox open
Now I remote desktop from my laptop, while away from the server room, to the server with the same domain\administrator password. Obviously I should be able to run firefox from that desktop. I can run IE6 or IE7 from both desktops, so why not firefox.
For those that say I shouldn't log in as administrator, then say I'm logging in as domain\user.name . The fact of the matter is there's many scenarios where windows admins might want to log into mutliple desktops. What if you have a terminal where someone gets access with the guest account via a citrix or terminal services connection? Obviously they all should be able to run firefox. This is definately a bug.

Any attempt to say this is valid behavior (which I potentially agree with, for what that's worth coming from yet another user) should probably be accompanied by an explanation of what's supposed to happen if one of the two logged-in accounts changes preferences, bookmarks, browsing history, or any other user-specific data.
The other one automatically implements the change too? Conceivably that could completely break their browsing attempt, e.g., you turning off JavaScript and CSS for debugging while I'm trying to use Gmail. Moreover, it could probably be used to inject arbitrary content into the browsers of all other users using the same account, by installing a Greasemonkey script or custom CSS or what have you. Preference-warring would be fun too, changing back and forth until one side gets sick of it and logs out.
The other one ignores the change? Then what happens if both make changes? Merge them? It's perfectly possible they'll conflict or overlap in some way that can't be automatically detected. The second change just overwrites the first? Possibly the most palatable scenario so far, but pretty confusing and annoying when your changes are silently rejected.
How about the second one to log in allows an option to clone a snapshot of the account for the duration of the session and then destroy it, with a suitable warning message on startup? ("Note: someone else is logged in using this profile. When you shut down Firefox, changes to your profile [or: to your settings] will not be saved. OK/Cancel") This satisfies the "oh, damn, I must have left it running on the other computer" problem well enough, while not causing profile change conflicts. It would even be usable for the guest situation, but there you'd probably want the profile unwritable to start with, with no warning. This superficially seems like a reasonable possibility.
You say IE6 and IE7 work from both profiles. What do they do? Silently merge/overwrite changes?

Thanks for the response. I will play with IE tommorow on Server 2003 and see what happens to the various preferences. Keep in mind my only reason for doing this is being able to browse the web, I don't normally worry about bookmarks, etc. I just want to be able to login to windows 2003 server and run firefox and google some quick info for whatever sort of question I have at the time. I don't want to have to deal with silly IE and the security features built into server that make it a pain to use.

I agree that this is definitely a bug. When I click on the Firefox icon and it won't run because "Firefox is already running" even though there is no firefox process at all on this machine, that is a bug. I am using IE right now because of it.
I have roaming profiles set up for my users, so that if a workstation goes down or needs to be serviced they can simply log in to another and have all their stuff available. Right now I am logged in to the server with my own login while some maintenace tasks are being carried out. I must have also left firefox running, because I am physically logged in at another machine and it won't let me run firefox.
This is really annoying. I shouldn't have to write scripts or programs just to use my browser, and if one of my users happens to log in at two locations (which will likely happen once some machines are added to our conference room) they won't know why it is not working and I will get a call. They are not going to care about why it is a better design or whatever. To them if they click the icon and it doesn't open, it is a crash.
I realize this is an old report, but I think it should be discussed further.

1. fix your computer's configurations to not roam mozilla's profiles.
---
2. install weave http://labs.mozilla.com/projects/weave/
3. configure weave so that each user sessions syncs for their user to your login server.
if weave doesn't fulfill your needs, file bugs w/ them.
---
for people w/ sessions who don't care about anything else, you can write
here's a conceptual .bat file
:: handle-multiple-sessions.bat
set FIREFOXDIR="C:\Program Files\Mozilla Firefox"
set PROFROOT="%APPDATA%\Mozilla\Firefox\Profiles"
cd /d %PROFROOT%
set PROFNAME=%COMPUTERNAME%-%SESSIONNAME%
if exist "%PROFNAME%\." goto session
for /d %a in (*default) do set DNAME=%a
if not exist "%DEFNAME%\parent.lock" goto default
xcopy /e "%DEFNAME%" "%PROFNAME%\"
del "%PROFNAME%\parent.lock"
:session
"%firefoxdir%\firefox.exe" -P "%PROFROOT%\%PROFNAME%" %@
goto done
:default
"%firefoxdir%\firefox.exe" %@
:done
if you change the firefox associations (including the ones in the registry) to use this bat file instead of firefox.exe, it should automagically do something that would almost work.
however, you really should just figure out what features are missing in weave and ask for them. automatically setting up a weave account within a domain seems like a great request.

I agree with others that is is a bug rather and not a desirable design feature.
Why? Because I see the same symptom - regularly - when I close the browser window and restart. No second user logged in, no concurrent logins from one user, single user machine, only one profile. Simply exiting the browser and restarting it triggers the symptom. It is intermittent, but - from the time of closing the browser window - I've seen the symptom anything up to one minute later. And this is with a reasonably capable machine, no other user processes running.
I am seriously considering abandoning firefox in favour of another browser because of this.
I accept the need to synchronise access to a profile (eg prevent the profile being changed by two processes concurrently). However, the only time that should be a concern is when saving changes to the profile. That does not justify the browser instance keeping the profile locked indefinitely.
If you're worried about preventing user X accessing a profile of user Y, then use operating system features to help. Create the profile (directory, files, etc) so it is only readable by the owner. No need for special locking mechanisms at all.
If you're worried about one browser instance changing a profile that has been loaded by another instance (with, presumably, both instances run by the same user account) then establish some notification scheme (i.e. the process that makes the changes does something that can be detected by the other, so the other can respond appropriately).

A few years later, and it's still a pain. Also affects Google Chrome, btw.
The reason this occurs is due to a design decision, this doesn't mean the issue doesn't still occur. It seems strange to me that it's marked as INVALID. I guess that means, too much effort required for too little gain.
I have a few ideas:
1. Improve the error message - "You already have Firefox open in another session for the same user account. Only one instance is supported per user."
2. Or the more jovial "Hey minority user, use IE"
3. Let Firefox start without all the bells and whistles, a Bare Mode. This could be used both in this situation and also as an optional configuration for people who prefer a simpler experience.
4. Marshalling to the other session. Can that work with IPC across sessions? I think not.
I suspect (1) is the only option the dev team would be willing to consider, briefly.