558190 - Plugin container process name needs to be more appropriate

Status: RESOLVED FIXED

(Core :: IPC, defect)

Description

[Alex Limi (:limi) — Firefox UX Team]

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.

Comment 1

[Mike Beltzner [:beltzner, not reading bugmail]]

While I don't think this blocks, I do think that we should stretch to get it if possible.

Comment 2

[Benjamin Smedberg]

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.

Comment 3

[Mike Beltzner [:beltzner, not reading bugmail]]

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.

Comment 4

[Mike Beltzner [:beltzner, not reading bugmail]]

(Vehement is strong - but I do really think that you're optimizing for the wrong audience, and in the wrong ways!)

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I also feel very strongly that the name 'mozilla-runtime.exe' is highly inappropriate. 'plugin-container.exe' is much better.

Comment 6

[Alex Limi (:limi) — Firefox UX Team]

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.

Comment 7

[Alex Limi (:limi) — Firefox UX Team]

(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 :)

Comment 8

[Benjamin Smedberg]

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.

Comment 9

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

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.

Comment 10

[Mike Beltzner [:beltzner, not reading bugmail]]

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?

Comment 11

[Benjamin Smedberg]

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.

Comment 12

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Can we just run the partial-update tests over it? I think we have pretty good coverage there, if I understand correctly.

Comment 13

[Benjamin Smedberg]

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.

Comment 14

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

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.)

Comment 15

[Benjamin Smedberg]

Bug 535090, as comment 11 said.

Comment 16

[Mike Beltzner [:beltzner, not reading bugmail]]

I do think that this should block, as it seems doable and has a great upside from a product and user perspective.

Comment 17

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Attachment: Patch, v1

This renames mozilla-runtime to plugin-container. I think I hit all the right spots?

Comment 18

[Ben Turner (not reading bugmail, use the needinfo flag!)]

http://hg.mozilla.org/mozilla-central/rev/25879ce33e7a

Comment 19

[Carlos Alén Silva]

I noticed this bug after it was fixed :(

I was going to propose "mozilla-plugins.exe" as a replacement for "mozilla-runtime.exe".

Comment 20

[LegNeato]

a=clegnitto for 1.9.2.4

Comment 21

[Alex Limi (:limi) — Firefox UX Team]

You are all awesome. Thanks for doing this. It warms my cold, stony UX heart.

Comment 22

[Ben Turner (not reading bugmail, use the needinfo flag!)]

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

Comment 23

[IU]

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.

Comment 24

[Bill Gianopoulos [:WG9s]]

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.

Comment 25

[Al Billings [:abillings - ex-MoCo]]

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:1.9.2.4pre) Gecko/20100413 Namoroka/3.6.4pre).