1261416 - 32bit Firefox would not launch Flash Player with Flash Player's protect mode

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Alice0775 White]

32bit Firefox would not launch Flash Player with Flash Player's protect mode.


Steps To Reproduce:
1. Install Flash Player 21.0.0.197
2. Start 32bit Firefox under 64bit Windows7
3. Open http://www.adobe.com/software/flash/about/
4. Observe task manager process lists

Actual Results:
There are no FlashPlayerPlugin_21.0.0.197.exe *32 process


Expected Results:
There should be two FlashPlayerPlugin_21.0.0.197.exe *32


Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=906bb507cee3daac0120c0fa75ade9b2033b0108&tochange=8f159c5d671e045cecf67b95b1e75b9362937f08

Regressed by: 
8f159c5d671e	George Wright — Bug 1114647 - Rename "plugin-container" to "firefox-webcontent" and create a new executable target for Win32 called "firefox-plugin-container" r=ted,jhamer

Comment 2

[Benjamin Smedberg]

Anyone want to bet that Flash is checking the .exe name?

Comment 3

[(not currently active) Ted Mielczarek]

I don't actually know how the Flash plugin stuff works. Maybe we missed something in the firefox-plugin-container binary that was present in the old plugin-container binary? Alternately, it's possible that Adobe is sniffing the binary name or something like that.

Comment 4

[George Wright (:gw280) (needinfo me!)]

It seems very likely to me that Flash is sniffing the plugin container executable name. Benjamin already ran strings and found plugin-container.exe in there.

I think our best course of action here is to just revert the name of the plugin container executable back to plugin-container.exe. Sadface.

http://hg.mozilla.org/integration/mozilla-inbound/file/tip/old-configure.in#l7233 should be the only line that needs changing. I'll test and see.

Comment 5

[Jeromie Clark]

You guys are always welcome to request changes from us.  We're happy to support you where we're able to.

Comment 6

[Jeromie Clark]

Also, just to be super clear, we do check that the hosting process has a name that we expect.  We wanted to mitigate the possibility of a malware shim sitting between Flash and Firefox.

Comment 7

[George Wright (:gw280) (needinfo me!)]

Attachment: 0001-Bug-1261416-Rename-firefox-plugin-container-back-to-.patch

So for some reason I could have sworn when I tested this last time it correctly launched plugin-container.exe for plugins, but I guess it didn't. There was a bug in the rename patch which caused it to unconditionally launch firefox-webcontent.exe because XRE_GetProcessType() always returned the parent process type. This patch resolves that issue.

This patch also reverts the name for the plugin process back to plugin-container.exe.

I have verified that this patch works with flash locally in 32-bit and that both firefox-webcontent.exe and plugin-container.exe launch as expected when we load a child process or a plugin respectively.

Comment 8

[George Wright (:gw280) (needinfo me!)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=468051ba851f

Running through try to make sure we don't break more stuff with this.

Comment 9

[Jonathan Howard]

Linux is working with firefox-webcontent. I have no idea if continuing to use just the one executable for both plugins and content is intended.

Comment 10

[(not currently active) Ted Mielczarek]

Comment on attachment 8737357 [details] [diff] [review]
0001-Bug-1261416-Rename-firefox-plugin-container-back-to-.patch

Review of attachment 8737357 [details] [diff] [review]:
-----------------------------------------------------------------

::: build/win32/Makefile.in
@@ +31,4 @@
>  ifndef CLANG_CL
>  check::
>  	$(PYTHON) $(srcdir)/autobinscope.py $(DIST)/bin/$(MOZ_APP_NAME)$(BIN_SUFFIX) $(DIST)/crashreporter-symbols/
> +	$(PYTHON) $(srcdir)/autobinscope.py $(DIST)/bin/$(MOZ_CHILD_PROCESSN_NAME) $(DIST)/crashreporter-symbols/

Looks like you have a typo here.

::: toolkit/mozapps/installer/make-eme.mk
@@ +10,2 @@
>      # exists, and where voucher.bin will be generated.
> +    MAKE_SIGN_EME_VOUCHER = $(PYTHON) $(MOZILLA_DIR)/python/eme/gen-eme-voucher.py -input $(1)/plugin-container.exe -output $(1)/voucher.bin && \

Might as well use $(MOZ_PLUGIN_PROCESS_NAME) here.

Comment 11

[George Wright (:gw280) (needinfo me!)]

(In reply to Jonathan Howard from comment #9)
> Linux is working with firefox-webcontent. I have no idea if continuing to
> use just the one executable for both plugins and content is intended.

Right now that's intended for Linux. A decision wasn't made for whether Linux should go with the two process "hack" or whether it can go single process like OS X can (the real issue is whether on Linux we can distinguish different processes using some means other than just the process. I don't believe we can). I went with the option that'd keep things simpler for now.

Comment 12

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/4565c4fac8b0

Comment 13

[Liz Henry (:lizzard)]

After this lands in nightly you may need to look at bug 1260130. That's marked as affected for 46 and 47. Does this issue also affect other branches?

Comment 14

[George Wright (:gw280) (needinfo me!)]

Sure, I'll keep an eye on it. I don't think it's related though, as that bug pre-dates the patch which caused this breakage.

Comment 15

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/4565c4fac8b0

Comment 16

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/8d87452bfc44

Comment 17

[Ryan VanderMeulen [:RyanVM]]

Merge of backout. Leaving this resolved, however, since bug 1114647 was also backed out.
https://hg.mozilla.org/mozilla-central/rev/8d87452bfc44