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)
Tracking
(firefox48blocking fixed)
RESOLVED
FIXED
mozilla48
People
(Reporter: alice0775, Assigned: gw280)
References
Details
(Keywords: regression)
Attachments
(1 file)
13.22 KB,
patch
|
ted
:
review+
|
Details | Diff | Splinter Review |
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)
Comment 2•8 years ago
|
||
Anyone want to bet that Flash is checking the .exe name?
tracking-firefox48:
--- → blocking
Updated•8 years ago
|
Assignee: nobody → gwright
Comment 3•8 years ago
|
||
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.
Updated•8 years ago
|
Assignee: nobody → gwright
tracking-firefox48:
--- → blocking
Assignee | ||
Comment 4•8 years ago
|
||
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)
Comment 5•8 years ago
|
||
You guys are always welcome to request changes from us. We're happy to support you where we're able to.
Comment 6•8 years ago
|
||
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.
Assignee | ||
Comment 7•8 years ago
|
||
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)
Assignee | ||
Comment 8•8 years ago
|
||
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•8 years ago
|
||
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•8 years ago
|
||
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+
Assignee | ||
Comment 11•8 years ago
|
||
(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 13•8 years ago
|
||
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)
Assignee | ||
Comment 14•8 years ago
|
||
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)
Comment 15•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/4565c4fac8b0
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
Comment 17•8 years ago
|
||
backout bugherder |
Merge of backout. Leaving this resolved, however, since bug 1114647 was also backed out. https://hg.mozilla.org/mozilla-central/rev/8d87452bfc44
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•