Closed Bug 1261416 Opened 8 years ago Closed 8 years ago

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

Categories

(Core Graveyard :: Plug-ins, defect)

x86
Windows 7
defect
Not set
normal

Tracking

(firefox48blocking fixed)

RESOLVED FIXED
mozilla48
Tracking Status
firefox48 blocking fixed

People

(Reporter: alice0775, Assigned: gw280)

References

Details

(Keywords: regression)

Attachments

(1 file)

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
Flags: needinfo?(ted)
Flags: needinfo?(gwright)
Anyone want to bet that Flash is checking the .exe name?
Assignee: nobody → gwright
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.
Assignee: gwright → nobody
Flags: needinfo?(ted)
Assignee: nobody → gwright
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.
Flags: needinfo?(gwright)
You guys are always welcome to request changes from us.  We're happy to support you where we're able to.
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.
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.
Attachment #8737357 - Flags: review?(ted)
https://treeherder.mozilla.org/#/jobs?repo=try&revision=468051ba851f

Running through try to make sure we don't break more stuff with this.
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.
Blocks: 1261643
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.
Attachment #8737357 - Flags: review?(ted) → review+
(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.
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?
Flags: needinfo?(gwright)
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.
Flags: needinfo?(gwright)
https://hg.mozilla.org/mozilla-central/rev/4565c4fac8b0
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
Merge of backout. Leaving this resolved, however, since bug 1114647 was also backed out.
https://hg.mozilla.org/mozilla-central/rev/8d87452bfc44
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.