There should be a way to start various mozilla components (i.e. browser, mail, etc.- the things in the Task menu) in separate processes. (Apologies, my thread/vm/process mgmt vocabulary isn't quite up to speed- I'm not sure if "process" is exactly what I mean, since they do each get separate processes, right? although starting a new browser instance attaches to the parent proc rather than creating a new one.) Currently if the browser crashes, it also takes out my mail client. current example behavior: mozilla & mozilla -mail & ctrl-q (both are killed) desired behavior: mozilla & mozilla -mail -noattach & // or something ctrl-q (only the one with focus is killed)
Are you using the RPM builds?
yes- am I missing something obvious?
Just checking before assigning this bug to the guy who maintains the startup script in those builds. :) As a warning, running two separate mozilla processes on the same profile will currently result in problems (data corruption) if both processes attempt to write to the history database (and maybe the mail database). You may be safe if you use one for mail only and one for browsing only, though.
Status: UNCONFIRMED → NEW
Ever confirmed: true
oops. forgot to reassign
Assignee: asa → blizzard
Sounds dicey. Making those resources safe for access/mutation by multiple processes is probably a prerequisite. This is something that's been annoying me lately: Mozilla and Galeon use different caches and histories. I think that's silly. I've filed bug 134959 on this.
*** Bug 135176 has been marked as a duplicate of this bug. ***
Severity: enhancement → normal
Component: Browser-General → XP Apps
OS: Linux → All
QA Contact: doronr → ian
Hardware: PC → All
Summary: [RFE] Should be able to start "tasks" as different processes → Each app should run in a separate process (Should be able to start "tasks" as different processes)
Target Milestone: --- → Future
Whiteboard: [Hixie-PF][Hixie-3.0]DUPEME → [Hixie-PF][Hixie-3.0]
Does this bug include the idea that each navigator browser instance (window) should also optionally be run as a separate process? Or would that be a new bug? This is a feature of IE that in earlier versions was an optional configuration and now just happens if you have sufficient memory. It's nice to only lose one browser window if something crashes.
It probably wouldn't be too hard to add that if the rest was implemented.
Whiteboard: [Hixie-PF][Hixie-3.0] → [Hixie-PF][Hixie-3.0][MB]
Fixing this bug would especially be useful for the download manager, see bug 131871
The View Source component should also be one of these separate components (as per bug 145021).
Depends on: 145021
Whiteboard: [Hixie-PF][Hixie-3.0][MB] → [Hixie-3.0][MB]
Is there a chance that this feature will allow us to isolate the browser from plugin failures (by running plugins in a separate process)? If yes, then bug 36272 should be reopened.
Aleksey: Running plug-ins in a separate process is an issue separate from both this bug and bug 36272.
Some thoughts about this bug: Today if Mozilla is crashing we do not only lose the data in the crashed component, but also in the other comonents running at crash time. So this is also a dataloss issue. If we can start a comonent as a seperate processe we would only have to check at startup of it if it's already running, if not everythig is ok and we can start, if it's already running the it depends... ...2 instances of MailNews eg are not good for our Mailboxes ;) ...2 instances of the dl manager also won't work together, because they use the same files to store information about downloads, iirc ...but if Navigator is already running we could just open a new navigator window, it would make no difference to the user. Well, I don't know if every component is using it's own files/databases to store its information, if not this could be a problem.
*** Bug 53945 has been marked as a duplicate of this bug. ***
*** Bug 130440 has been marked as a duplicate of this bug. ***
see bugs http://bugzilla.mozilla.org/show_bug.cgi?id=90293 and http://bugzilla.mozilla.org/show_bug.cgi?id=34819 The first bug is about making a stand alone mailnews application. The other bug is about implementing altmail, which would allow the mozilla browser to still have all the UI hooks for mail, news and addressbook. But those UI hooks would launch the default applications. If the default application was the stand alone mozilla-based mailnews app, we'd be done.
Having Mail run separately would not mean that we were done. See comment 7 for a list of the apps that should be separated. Separating Mail alone would be insufficient (although a start). Also, as per comment 8 and comment 9, individual sessions of each application (including Navigator) should run in a separate process.
*** Bug 176194 has been marked as a duplicate of this bug. ***
Would it help if configuration, profile, etc were handled be a separate process, possibly running as a service/daemon? I don't know how components currently access this information, but if they do it directly rather than through an interface, I guess it could represent a rather large change. It seems to me that if this was split off like this, start up times might be reduced and profile management could be drastically improved. I would imagine that it would also make data corruption due to concurrency of a process per component easier to manage.
Is this an issue of IPC, too? IMO when parts of Mozilla were implemented in different parts, there'll be a need of effective IPC between the components. Furthermore some common service-apps like a Profile-DB, or a UI-Server (X++) would be a good thing. As mentioned in #20 already this could solve some other problems. However those common service-apps have a risk of crashing all components that depend on them. Just like when your X-Server crashes, then your X-Programms will die, too. But if properly implemented this shouldn't be a unsolveable issue. Finally such an implementation with different processes for different components would enable Mozilla as a platform for a lot of OpenSource Projects like FileManager, MediaPlayer, ... There are already promising projects at mozdev but their usability suffers from mozilla-apps running in only one process.
Don't the availability of Firefox and Thunderbird obviate the need for this bug? At this point, is it really thought that the suite will move in this direction?
(In reply to comment #22) > Don't the availability of Firefox and Thunderbird obviate the need for this bug? No. it's actually orthogonal to that. > At this point, is it really thought that the suite will move in this direction? At this point, it's not entirely clear in which direction the suite will move in the long-time future. We know a short-time and a likely mid-term strategy but we don't know where we want to go in the long term, so we also don't know yet if this bug can still be considered valid or not.
yeah, I'd say this is won't fix...
It's still valid unless the component owner (not sure who that would be under the new management) marks it as such. At this point, I wouldn't mark *any* Mozilla bug as WONTFIX - because it could just cause chaos when/if they start being reopened after the changeover. Let the new owners make that decision.
FWIW, there are a few reasons why FFox + Tbird != Moz Suite, even excluding obvious ones like IRC & Composer: 1: memory footprint as mentioned in comment 7. Moz can share core resources between components, whereas the standalone apps each load their own instances. This could be solved alternately by separating out a complete backend library which is called by any Moz-based app, but that's another bug entirely. I'd be happy with either solution. 2: ease of administration. 1 suite is easier to install/maintain/update than 2 or 3 or more apps.
As a server-side programmer, I am tangling with the issue of people opening multiple browser windows (in the same process) and getting the same http-session information shared as a consequence. In IExplore you can still start the browser in a new process and hence get a fresh http-session and consequently separated server-side session upkeep (or re-use the process with ctrl-N and share the server-side session). In Mozilla 1.7 / FireFox 1.07 there is no facility to force a new process (and hence a distinctly separate server-side session). I know that this is technically a different issue to that of starting different processes in a multi-user environment, but while this issue is boing considered, I would like to lobby for some help for the poor server-side programmers who have to deal with this conundrum. I would love to see a feature that allows users to choose to start the browser windows according to their needs: same session, or distinct session. I suggested on a forum elsewhere that it would be ideal to have a setup option to have Tabs start in the same process (and hence share serverside session information), and Windows start in a new process (and hence NOT share serverside session information). At the UI level this would amount to a simple pair of radio buttons in the "Prefs" "Advanced" area. Alternatively or as well, it would be great to have a menu option like "New Window" but "New Session". Obviously this will baffle the punters to some degree. That is of course if Mozilla can sustain being run in separate processes at all. I originally put this comment in https://bugzilla.mozilla.org/show_bug.cgi?id=247186 but I think this is more key to the issue ... other Bugs that seem related: https://bugzilla.mozilla.org/show_bug.cgi?id=219984 Thanks for listening. Rob
Whether or not the browser uses the same session is orthogonal to whether it is running in the same process. See the OSI layers to understand this. http://en.wikipedia.org/wiki/OSI_model
(In reply to comment #28) > Whether or not the browser uses the same session is orthogonal to whether it is > running in the same process. See the OSI layers to understand this. > > http://en.wikipedia.org/wiki/OSI_model > Excellent! Then may I extrapolate from that pearl of wisdom that it is in the browser software author's power to just engage a different http session that is naturally distinguishable from the server without any programmatic trickery, wherether or not the browser instance is in a new process / thread or whatever? Is it therefore accurate to say that it has just been a chosen natural default that browser authors have opened a new http session when they've used a distinct process for a new browser window (eg: IE), and reused the same session when they've shared a process for browser windows? (Obviously this is not necessary, just how it's been done in practice). Given that this is true, I would say that my pleas for a feature that allows a user to deliberately open a distinct server-side "session" is not part of the "start browser in a new process" Bug or conversation. I guess I'll start looking for it elsewhere, or start a new Bug ... ? If nothing else hopefully this thread will be googleable and others trying to figure out their serverside code session problems will find it.
ignoring the fact that HTTP knows no sessions, you were probably looking for bug 117222. this bug is about the ability to run browser, mail and irc client (say) in different processes; not to launch several instances of the browser.
(In reply to comment #30) > ignoring the fact that HTTP knows no sessions, you were probably looking for > bug 117222. this bug is about the ability to run browser, mail and irc client > (say) in different processes; not to launch several instances of the browser. > Well, at least I'm learning a few things about some areas I've not been expsed to yet. Thanks, for your corrections to my technical errors. It stands that web-app server-side coders (I deal in j2ee, currently using Tomcat 5, Struts 1.2) can't naturallly distinguish between multiple browser windows open on a single client PC in Mozilla (or separately in Firefox, and likewise in IExplore windows opened via Ctrl-N. Using (java) HTTPRequest request.getSession() returns the same object (and hence serverside cached state) irrespective of which specific window a request came from, and it's a damn pest for the serverside coder not to be able to distinguish which of multiple open windows on a clients box sent a request, as the user may have changed some fundamental context material in another window. The only solutions on offer around seem to be to put in a single-use url variable to trace the identity of a window and trap attempts to reuse that variable by other windows. I'm not especially happy about that means. With respect, I don't think that my topic relates to mail and irc, though the technology may ultimately have concurrence. Clearly I'm a minnow in these waters though so I don't want to assume too much about what I may or may not know.
(In reply to comment #30) > ignoring the fact that HTTP knows no sessions, you were probably looking for > bug 117222. this bug is about the ability to run browser, mail and irc client > (say) in different processes; not to launch several instances of the browser. > Ok, thanks for that steer Christian, now having read https://bugzilla.mozilla.org/show_bug.cgi?id=117222 ... yes ... that IS the correct Bug for what I've been talking about. What a travesty that Bug is! You developers must hate it. I feel sorry that I whinged and I can't help. Anyone else who trips across this bug, look at 117222 before commenting any more here about what I was talking about. It has loooong and intense history. Sorry again for puluting this bug with comments. This bug is only relevant in that it is by allowing new browser instances that IE manages to provide server-side session indepandance. Thanks for your polite patience. Cheers Rob
Assignee: blizzard → jag
QA Contact: ian
Target Milestone: Future → ---
Given the restrictions and assumptions that profiles impose upon us, I don't see this ever likely being feasible, do you?
Assignee: jag-mozilla → nobody
1. Make an option for network mode where you switch to a different profile location (just move the files to the local hard drive instead of the network drive). I would prefer to be able to have a different profile on every machine then have to only have one firefox open across my many log ins. I did every computer in the company I worked at with the same log in and just walked or ran around them all putting them to the next thing that needed to be done while everybody had gone home after work. 2. Evolve the profile. This would be more of a long term goal where you plan on changing the profile so it not only works better but also knows when and how to have multiple instances open. As I said not necessary for them all to be the same profile, it is for them to be able to open. 3. Make a separate version of firefox for network users that is on the channel page or just as a different project. This would have a different profile system that can handle being on a network with more than one log in. Maybe your/were looking at this wrong. Maybe trying to change firefox is too big so making a separate project would allow you to do all the things you can't do because it wouldn't be good for most users. Here's an idea. How about you start with option three and make a separate project so that you start the ball rolling towards the development of a working system. Then you introduce that system back into the main firefox as an option in the network settings. This would make it easy to go between versions. Even if it took a while transferring between versions and had a giant warning if you tried to. Then when your confident enough in this new method you could start mixing it into the main system as an experiment until you have it in the standard version which does both as seamlessly as if it were just one computer. I don't care if this take many years but I don't want the community just to give up on it because nobody had the courage to think outside of the box. Thank you for your time.
... I've commented on the wrong bug haven't I... I was thinking of the one that doesn't is only one log-in per domain network per log-in. As in a system where you log into the same user profile on multiple computers across a network you can only open firefox on one computer if your logged into multiple computers with the same user profile. The people on that project just gave up and I've been trying to get them back on track. When I saw is it feasible I got a bit excited that somebody didn't just want to give up and go do something else so I wrote this up in a hurry. On the other hand you could just imagine this method as potential method to fix this problem and many others.
You need to log in before you can comment on or make changes to this bug.