Closed Bug 558190 Opened 10 years ago Closed 10 years ago
Plugin container process name needs to be more appropriate
mozilla-runtime.exe is a confusing name for the plugin container in Lorentz. plugin-container.exe seems to be the preferred name in a straw poll of developers on IRC, and then we should put "Plugin Container for Firefox" in the app details. There's no need to invent namespaces as part of the actual process name, you can always look up what the parent process is if you're interested. If my browser is slowing down, and I pull up the task manager and see "plugin-container" taking 100% of my CPU, it's predictable what will happen. Killing "mozilla-runtime.exe" is not. I know the argument has been made in the past that this process may be used to run Electrolysis stuff in the future, but I'd encourage us to cross that bridge when we get there, and not confuse our users in the meantime.
While I don't think this blocks, I do think that we should stretch to get it if possible.
As noted in the newsgroups, I believe it's important that firefox or mozilla be somewhere in the name, so that those advanced users who do spend time in the task manager can know how to associate the process. However, I think that if we're going to make any change at all, we should just use firefox.exe for all processes, and avoid the extra executable altogether. I don't really support making any change at this point, however. FWIW, on Windows there is no user-visible way to associate a process with its parent without installing special tools.
Benjamin, I vehemently disagree. Advanced users will know what to look for because they will be advanced users, the likes of which know what all sorts of esoteric process names actually mean. Further, the "Plugin Container for Firefox" pretty name will help anyone who's trying to figure out where plugin-container.exe comes from. Non-advanced users will have the exact fear that Limi mentions, which is that mozilla-runtime will kill their Firefox and they'll lose their data. Or that the mozilla-runtime is spiking their CPU without realization that it's being caused by plugins. From a product perspective, and user experience perspective, this is a clear win.
(Vehement is strong - but I do really think that you're optimizing for the wrong audience, and in the wrong ways!)
I also feel very strongly that the name 'mozilla-runtime.exe' is highly inappropriate. 'plugin-container.exe' is much better.
Well, we already have confused users in the field (from Reddit): > Yup; works in Minefield. My build (2010/3/12) isn't as advanced, though. > Flash/Acrobat plugin processes are listed as mozilla-runtime in the task > manager, but can be killed separately.
(In reply to comment #2) > I don't really support > making any change at this point, however. Can you elaborate? It's just a process name, a search/replace would be able to do this — are there other reasons why we shouldn't do it than personal preference? (not trying to be facetious, genuinely curious, as this seems like a no-brainer to me :)
We had to special-case the existing name in the partial update scripts, at least, and I know it's compiled in one other place. Since we have known bugs relating to using a different executable (firewall whitelists don't know about m-r, and the windows 7 audio mixer treats it as a different program), I think we should if anything just switch to using firefox.exe throughout.
The windows 7 mixer treating it as a different program is a feature, per many people. I really really don't think we should call it firefox.exe until we have a process manager working for users to refer to, and I think that having slimmer hosts for plugins/jetpacks (without all of libxul, f.e., of which we need a vanishing fraction) is a better longer term direction than using the same executable for everything. (Like, when we get networking in another process, I would rather not have to worry about the necko code being in the libxul that we have to load at startup, because code size is a major Ts factor.) If we special cased the name in various places, then I assume that those changes also came with tests, and simply searching the resulting binaries for the string "mozilla-runtime" will provide further confidence. I admit I'm having a hard time teasing apart which part of your objection is due to engineering risk, and which is due to other pieces. The engineering risk is what should affect where and when we land a solution to this bug, but not really whether we should pursue it. I agree that we should name it something like plugin-container (I don't think that "mozilla" there really tells most users much, if that's the worry; the names in my process manager are mostly cybercrud anyway), should look at the best way to reduce risk from that minimal change, and evaluate whether we are comfortable making that change before shipping 3.6.4. Otherwise, we could ship it in 3.6.5, but I think that it will only amplify confusion to do so.
Shaver makes an excellent point in comment 9 - moving this to a blocking nomination. Benjamin, what would be involved in making this change from an engineering perspective?
blocking1.9.2: - → ?
It would at least involve makefile changes, DEFINES, install manifest, and removed-files. It looks like bug 535090 was finally fixed without special-casing mozilla-runtime, so it might be ok, but we'll need someone to verify that partial updates work correctly.
Assignee: nobody → bent.mozilla
Can we just run the partial-update tests over it? I think we have pretty good coverage there, if I understand correctly.
They didn't catch the bug the first time, IIRC, although they may have been updated. The problem was that the executable bit wasn't set properly, even though the file contents were correct.
Why wouldn't they have been updated? What test did we add for the fix we made to set the executable bit correctly? (You can just give a bug number and I can dig for myself, no doubt.)
I do think that this should block, as it seems doable and has a great upside from a product and user perspective.
blocking1.9.2: ? → .4+
This renames mozilla-runtime to plugin-container. I think I hit all the right spots?
Attachment #438178 - Flags: review?
10 years ago
Attachment #438178 - Flags: review? → review?(benjamin)
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
10 years ago
Attachment #438178 - Flags: approval188.8.131.52?
I noticed this bug after it was fixed :( I was going to propose "mozilla-plugins.exe" as a replacement for "mozilla-runtime.exe".
a=clegnitto for 184.108.40.206
You are all awesome. Thanks for doing this. It warms my cold, stony UX heart.
Backed out and relanded, tests failed but then magically cleared on a "spelling change" in unrelated code. Grr. http://hg.mozilla.org/mozilla-central/rev/b66b7330b505
As Carlos suggested, wouldn't "mozilla-plugins" been a much more reasonable name? When I first saw "plugin-container" in Task Manager, I thought I had been infected with a virus. I think the chosen name may cause some confusion and panic with some users.
Actually, because under Windows/XP there is no good way to tell the ownership of a process or to display the pretty name. I think it really needs to include brandShortName for the case where you have multiple Mozilla applications running simultaneously that have plugins running. However this bug is closed so I will file a new bug.
Verified that this is changed to plugin-container.exe on Windows 7 with the latest nightly build (Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:220.127.116.11pre) Gecko/20100413 Namoroka/3.6.4pre).
You need to log in before you can comment on or make changes to this bug.