Closed Bug 1261416 Opened 4 years ago Closed 4 years ago
32bit Firefox would not launch Flash Player with Flash Player's protect mode
32bit Firefox would not launch Flash Player with Flash Player's protect mode. Steps To Reproduce: 1. Install Flash Player 126.96.36.199 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_188.8.131.52.exe *32 process Expected Results: There should be two FlashPlayerPlugin_184.108.40.206.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
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.
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.
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.
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?
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.
Merge of backout. Leaving this resolved, however, since bug 1114647 was also backed out. https://hg.mozilla.org/mozilla-central/rev/8d87452bfc44
You need to log in before you can comment on or make changes to this bug.