User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:2.0b6pre) Gecko/20100909 Firefox/4.0b6pre Build Identifier: Deliberately duping Bug 559142 as per the comments therein. x64 Windows builds of Firefox cannot use i386 plugins, despite the plugins operating OOP, and despite the OS having a built-in compatibility layer. This is being investigated for Mac (Bug 559142) and Linux (Bug 588749). Reproducible: Always

In case someone is working on this, best to wait until the patch for bug 590057 lands. That will provide fixes for Windows as well, including a foundation for architecture preference.

At present, we can't get 32-bit browser's path from registry key reliably if the browser is per-user installed. See bug 633804 for details.

You actually can't get the browsers path reliably from the registry since multiple installations of the same version will also overwrite other installations, a zip build doesn't add the registry keys, and I highly suspect that portable Firefox doesn't add the registry keys. We have never relied on registry keys in the past for Firefox to operate properly and the only reason the registry keys were added in the new installer is for backwards compatibility with the old xpinstall installer in case there were 3rd party applications that relied on the registry entries. I can't gaurantee that the registry entries you are trying to use are accurate for the reasons stated above and I think a more reliable method needs to be created instead of trying to repurpose these registry keys to accomplish what you want to in this bug.

Perhaps 64-bit browsers should be shipped with their 32-bit counterparts. Depending on other installation is inherently unreliable.

I think they would be the best path to take. btw: there is also bug 606468 to provide both 32 and 64 bit support for AccessibleMarshal.dll.

Removing dependency on bug 633804 since that isn't a reliable solution to this bug.

I have no time to complete the work. Feel free to take this.

(In reply to comment #9) > Created attachment 513239 [details] > MozillaBuild startup batch Kimura-san, I think that customizing mozilla-build isn't good way. We should use something like WinCE toolchain hack (arm-wince-gcc.exe) if we build universal package for Win64. Also, about mozconfig, it is better if we can use the following. (just idea) ac_add_options --target=x86_64-pc-mingw32 HOST_CC=cl HOST_CXX=cl CC=cl64.py HOST_CXX=cl64.py CROSS_COMPILE=1

Cross compile is not supported yet.

So your plan is to effectively build and ship two sets of binaries on Windows? I can see that working, but it means our build times would probably be >5 hours each.

(In reply to comment #12) > So your plan is to effectively build and ship two sets of binaries on > Windows? I can see that working, but it means our build times would probably > be >5 hours each. Now, Win64 PGO uses about 4 hours on Tinderbox, If we create combined package, it spends 6-7 hours at least. My idea is that 32bit plugin on 64bit firefox uses 32bit plugin-container of 32bit firefox of same version. IPC ABI is compatible (I need fix some bugs for shared memory), so It will work. But I have to discuss with Josh about 32-bit plugin support on 64-bit Firefox (Linux and Windows). Although Mac version can use Universal package of Mach-O, other platforms cannot.

Comment on attachment 539459 [details] [diff] [review] WIP v2 If building universal build for this, it spends 7 hours (3 hours for Win32 and 4 hours for Win64) at least. I think that this isn't good. This fix uses 32-bit installation from registry and use plugin-container of it. If nothing, we can use from prefs for 32-bit plugin-container path. If this idea is OK, I will make a reviewable fix. If bad, please suggest me about right idea.

My objections have already been noted in comment #4 and my comments following that comment

btw: there are at least a couple of other reasons using this method will break that I didn't previously note. There are likely other reasons as well since these are just off the top. 1. if the user doesn't also install the same 32 bit version of Firefox. 2. if the user updates one of the Firefox installs and not the other.

Comment on attachment 539459 [details] [diff] [review] WIP v2 I agree with Rob that this approach isn't robust enough.

(In reply to comment #18) > Comment on attachment 539459 [details] [diff] [review] [review] > WIP v2 > > I agree with Rob that this approach isn't robust enough. Josh, should I add new key like comment #5? Although I don't test yet, I am thinking another way. Firefox win64 extract 32-bit xulrunner into <installation path>/plugin-wrapper, firefox win64 uses 32-bit plugin-container of that xulrunner. How about this approach?

(In reply to Ted Mielczarek from comment #12) > So your plan is to effectively build and ship two sets of binaries on > Windows? I can see that working, but it means our build times would probably > be >5 hours each. Can't you build the two binaries in parallel? PGO is single-threaded anyway, so we're currently wasting CPU time waiting for it to finish. Or at least just build the parts of the 32-bit libxul needed by plugin-container.exe?

Now all of Flash, Java, Silverlight plug-in support 64-bit browsers. Is this bug still so important?

there is no 64bit shockwave ietab quicktime plugin divx plugins windows genuine and activation technology plugins (not that the 32bit versions actually work since Fx3.6 .....) realplayer Pando web booster (used in the downloading of some MMO's) Microsoft WMP Plugin MS Office 2010 (without installing the x64 version of office, which is not advised at this point) Comrade (GameSpy game browser) Canon Image Gateway Album plugin utility. The plugins you listed are barely a handful of whats available, and of them, Silverlight and Flash 64bit are still buggy as heck.

(In reply to Danial Horton from comment #22) > there is no 64bit > shockwave > ietab > quicktime plugin > divx plugins > windows genuine and activation technology plugins (not that the 32bit > versions actually work since Fx3.6 .....) > realplayer > Pando web booster (used in the downloading of some MMO's) > Microsoft WMP Plugin > MS Office 2010 (without installing the x64 version of office, which is not > advised at this point) > Comrade (GameSpy game browser) > Canon Image Gateway Album plugin utility. WMP Plugin is outdated (last update was 2007). > The plugins you listed are barely a handful of whats available, and of them, > Silverlight and Flash 64bit are still buggy as heck. I'm using flash 64bit over one year without bigger problems.

(In reply to speciesx from comment #23) > > WMP Plugin is outdated (last update was 2007). > But still necessary sometimes. AFAIK, there is no full-fledged alternative.

Opera released today Opera 64bit build and this build can also use 32bit plugins. http://dev.opera.com/articles/view/64-bit-opera-and-out-of-process-plug-ins/

Sorry, my English is very very poor. Maybe we can build one x64 version which can use both x64/x32 plugins at the same time. Maybe more simple, make a boolen switch inside about:config to choose only x64 or x32 plugins to run. The simplest way is to build two version: one for x32 plugins, and the other for x64 plugins. Finally you need spent double time to build it.

(In reply to s793016 from comment #26) > Sorry, my English is very very poor. > > Maybe we can build one x64 version which can use both x64/x32 plugins at the > same time. > > Maybe more simple, make a boolen switch inside about:config to choose only > x64 or x32 plugins to run. > > The simplest way is to build two version: one for x32 plugins, and the other > for x64 plugins. Finally you need spent double time to build it. This is because plugin-container depends on many modules, if we can make it depend on very few small module, the bug will be fixed easily. But bug 711386 has no progress now.

This bug needs to be cross platform as Linux will Integrate support for cross-architecture installation of binary packages (particularly i386<->amd64, but also other combinations)

(In reply to magnumarchonbasileus from comment #28) > This bug needs to be cross platform as Linux will Integrate support for > cross-architecture installation of binary packages (particularly > i386<->amd64, but also other combinations) We typically handle each platform in a separate bug for these types of bugs so please file a new bug for Linux.

That's already present (bug 588749).

Off the bug, I want to ask is there any methods to make x64 Fx support x86 extensions( using some dlls to complete some functions )?

(In reply to SpeciesX from comment #23) > (In reply to Danial Horton from comment #22) > > there is no 64bit > > shockwave > > ietab > > quicktime plugin > > divx plugins > > windows genuine and activation technology plugins (not that the 32bit > > versions actually work since Fx3.6 .....) > > realplayer > > Pando web booster (used in the downloading of some MMO's) > > Microsoft WMP Plugin > > MS Office 2010 (without installing the x64 version of office, which is not > > advised at this point) > > Comrade (GameSpy game browser) > > Canon Image Gateway Album plugin utility. > > WMP Plugin is outdated (last update was 2007). > > > The plugins you listed are barely a handful of whats available, and of them, > > Silverlight and Flash 64bit are still buggy as heck. > > I'm using flash 64bit over one year without bigger problems. i only noticed this nonsense just now. WMP plugin is not outdated, its required for the html5 video extension to work for crying out loud.

I think the "HTML5 Extension for Windows Media Player Firefox Plug-in" is outdated as well, the whole point of it is to allow Firefox to play H.264 videos by making it load WMP instead (Why it requires the other plugin), but Firefox can play H.264 video anyway. As for Silverlight and Flash, they seem to be installing the 64bit versions alongside the 32bit versions. At least on my system I never attempted to install them, yet I have the latest versions available.

I've been trying to port this into Firefox v32, the plugins get listed as available, but the instant you go to use one (e.g. Unity Web Player) it insta crashes the plugin the code has changed alot since the patch was originally made, is there a new version that I could take a look at, that might make this process abit easier Thanks

(In reply to Keloran from comment #36) > I've been trying to port this into Firefox v32, > > the plugins get listed as available, but the instant you go to use one (e.g. > Unity Web Player) it insta crashes the plugin > > the code has changed alot since the patch was originally made, is there a > new version that I could take a look at, that might make this process abit > easier > > Thanks I created 20.0 patch many months ago : https://github.com/xunxun1982/pcxfirefox/blob/master/patches/test/x64withx86plugin.patch When I have time, I will creat it based on new edition again. IPC code always changes, so maintaining the patch is very hard.

I don't think this is worth the effort. Adobe provides a 64-bit Flash plugin and we're actively trying to get rid of plugin usage in general.

(In reply to Ted Mielczarek [:ted.mielczarek] from comment #38) > I don't think this is worth the effort. Adobe provides a 64-bit Flash plugin > and we're actively trying to get rid of plugin usage in general. Agreed.