Open Bug 1162562 Opened 9 years ago Updated 2 years ago

Investigate converting Firefox to a Universal (UWP) application

Categories

(Core :: Widget: Win32, defect, P3)

Product:
Core
Component:
Widget: Win32
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
firefox40 --- affected

People

(Reporter: jimm, Unassigned)

References

(Blocks 2 open bugs,
URL
)

Details

(Whiteboard: tpi:+)

Attachments

(1 file)

Step-by-step conversion instructions for Firefox MSI within Desktop App Converter software by Microsoft
(deleted), text/plain
Details
This might be a crazy idea but if we can do it, it's a clean path forward on Windows that avoids the winrt restrictions we ran into with windows 8. The idea would be to resurrect our winrt widget layer and use it for both desktop and immersive os level input. We would then deprecate win32 widget on win10 and up. Some advantages: - geckos apps fully integrate into the new win10 environment regardless of device ‘mode’ (continuum support). - hopefully this would avoid the win8 requirement of porting libraries like netwerk over to winrt apis. Also it would have to avoid restrictions revolving around memory allocation and process management. - one unified widget layer which solves a big problem we had with win8 which forced us to create two apps instead of one. We would also be able to leave win32 widget 'in the dust' when supporting new features, like touch, which would save us a ton of time. http://blogs.windows.com/buildingapps/2015/03/02/a-first-look-at-the-windows-10-universal-app-platform/ Note, most of the old win32 desktop apps from Microsoft are getting ported over, including office and the edge browser.
Also, this could be a way for us to get onto other devices beyond pcs.
Blocks: windows-10
Some notes: - Project C isn't ready yet, won't be by win10 release, not clear when. - Seems to be the similar functionality as App-V or Spoon.net (Xenocode). - Will likely need code changes to work out of the box. Can probably be pre-tested by changing the manifest to run in AppContainer. - Can have things specified by appx manifest like live tiles and WinRT access. - Apparently the appx manifest can still be used even outside of the store if you want to run outside of the container. - Will enable on other devices like xbox and HoloLens. But only if you run inside the container. - Since the image conversion creator tool actually captures system dlls, I wonder how security issues are dealt with outside of our code from what we capture. Seems like a system update wouldn't update each image. - Updates through the store, less in our hands. Would probably need to maintain both in-store and out of store. - A lot of our widget/WinRT layer may be overhead since everything is virtualized for us for free through Project C. We may just want to add some integration code from the WinRT code into the Win32 code. - UAC stuff is blocked, no driver level stuff, IPC (e10s) stuff might or might not work out of the box
Notching this down the prio ladder for our initial win10 work because we don't have the resources to full-scale switch to winrt in the current timeframe, though that doesn't necessarily reflect longer-term priorities.
Priority: -- → P4
(In reply to Brian R. Bondy [:bbondy] from comment #3) > Some notes: > - Project C isn't ready yet, won't be by win10 release, not clear when. > - Seems to be the similar functionality as App-V or Spoon.net (Xenocode). > - Will likely need code changes to work out of the box. Can probably be > pre-tested by changing the manifest to run in AppContainer. > - Can have things specified by appx manifest like live tiles and WinRT > access. > - Apparently the appx manifest can still be used even outside of the store > if you want to run outside of the container. > - Will enable on other devices like xbox and HoloLens. But only if you run > inside the container. > - Since the image conversion creator tool actually captures system dlls, I > wonder how security issues are dealt with outside of our code from what we > capture. Seems like a system update wouldn't update each image. > - Updates through the store, less in our hands. Would probably need to > maintain both in-store and out of store. > - A lot of our widget/WinRT layer may be overhead since everything is > virtualized for us for free through Project C. We may just want to add some > integration code from the WinRT code into the Win32 code. > - UAC stuff is blocked, no driver level stuff, IPC (e10s) stuff might or > might not work out of the box Do we really need the Project Centennial stuff? I was thinking of swapping winrt widget for win32 widget and registering as a metro enabled browser just like we did in 8. I'm not sure what win10 supports here but it appears that these types of apps can paint to both desktop and immersive windows.
(In reply to Jim Mathies [:jimm] from comment #6) > Do we really need the Project Centennial stuff? I was thinking of swapping > winrt widget for win32 widget and registering as a metro enabled browser > just like we did in 8. I'm not sure what win10 supports here but it appears > that these types of apps can paint to both desktop and immersive windows. The Metro enabled browsers no longer work in Windows 10. If you are set as the default browser, you don't receive any special privileges, so Project C is the only way to have access to WinRT. Plus it would enable Firefox to be downloaded straight from the Windows Store.
Project Centennial has been released [1], it looks a simple install -> appx converter that allows classic desktop apps to be distributed through the store. Might be interesting to run fx through this and see what comes out / if it runs. Open question: determine if this would give our code base access to UWP apis that aren't marked DualApiPartitionAttribute. [1] https://www.microsoft.com/en-us/download/details.aspx?id=51691
> Open question: determine if this would give our code base access to UWP apis > that aren't marked DualApiPartitionAttribute. sounds like the answer to this question is yes. https://channel9.msdn.com/Events/Build/2015/2-692
Assignee: nobody → jmathies
Priority: P4 → P2
Whiteboard: tpi:+
Assignee: jmathies → nobody
Blocks: 795713
Summary: Investigate use of UWP + WinRT widget as a replacement for win32 widget → Investigate converting Firefox to a Universal (UWP) application
Priority: P2 → P3
This is more relevant with Windows 10 S which only supports apps from the store.
(In reply to Tim Nguyen :ntim (not accepting requests until 1st June) from comment #10) > This is more relevant with Windows 10 S which only supports apps from the > store. Actually this doesn't affect that a lot. Windows 10 S will only allow browsers or other "browser-like" apps that use Edge's html and js engines, so for that OS specifically a 3rd part browser would need to be built more like browsers on iOS: "10.2.1 Apps that browse the web must use the appropriate HTML and JavaScript engines provided by the Windows Platform." [1] [1] https://msdn.microsoft.com/en-us/library/windows/apps/dn764944.aspx#pol_10_2
Facebook has long been using non-Microsoft engine for its web view feature in its UWP app, with a long user agent string: Mozilla/5.0 (Windows NT 10.0.18282.1000; osmeta 10.3.8763) AppleWebKit/602.1.1 (KHTML, like Gecko) Version/9.0 Safari/602.1.1 osmeta/10.3.8763 Build/8763 [FBAN/FBW;FBAV/171.0.0.36.0;FBBV/123386314;FBDV/OEMB;FBMD/OEMB;FBSN/Windows;FBSV/10.0.18282.1000;FBSS/2;FBCR/;FBID/desktop;FBLC/en_US;FBOP/45;FBRV/0] So maybe there is a way to be permitted?

FWIW, this would be particularly useful to allow access to the Windows.Holographic API's which are not marked DualApiPartitionAttribute. Windows MR headset users currently have to work around this limitation by installing the separate "Windows Mixed Reality for Steam VR" application and have Steam running. If we were to use Windows.Holographic directly, no additional software would be required beyond Windows, Firefox, and the hardware drivers.

This would also allow for Fluent Design APIs to be implemented, like Acrylic for the background color (which, in my opinion, is the biggest reason to use Edge over Firefox).

But, as much as I want acrylic, is this actually possible?

I did a bit of investigation into this over Christmas.

In the current Windows SDK, there is a preview release of a new API that allows Win32 applications to host UWP UI. I was successfully able to create a window with an Acrylic background that follows the OS theme.

However:

This API has one significant limitation that makes us using the new API non-trivial: Each top-level window must run on its own distinct thread. This is different from our current model, where the Win32 UI thread and the Gecko main thread are one and the same, regardless of the number of top-level windows.

As it stands, we cannot use the UWP XAML Island API without separating the Gecko main thread from our UI threads, and without supporting separate UI threads per top-level window.

(Of course, I'm sure that some of these problems were already solved back in the Metro Firefox days, but the bottom line is that this would be hard to do incrementally.)

I successfully converted the most recent Firefox Stable build into a working AppX using the Desktop App Converter and dependencies. I've outlined a relatively easy method to conversion below, step-by-step, and will be attaching this as well as a .txt with .zip archive of the output packaged program.

Converting Firefox MSI Installer to Packaged Microsoft Store App for Windows 10 - Difficulty: Moderate to Easy.

Steps:
	1.	Create and label the following folders on C:\, including subfolders:
		a.	C:\Input
		b.	C:\Output
		c.	C:\Output\Firefox
	2.	Download and install Desktop App Converter from the Microsoft Store
	3.	Download the latest Firefox MSI installer at https://support.mozilla.org/en-US/kb/deploy-firefox-msi-installers
	4.	Rename the downloaded MSI file to a simple "Firefox.msi" and move to C:\Input
	5.	Open Desktop App Converter guide at https://aka.ms/converterdocs to review as we continue...
	6.	Follow the on-screen instructions until you get to "Package an app" (https://docs.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-run-desktop-app-converter#installer-conversion)
	7.	Now, enter the following into the Desktop App Converter, as Administrator:
		a.	" DesktopAppConverter.exe -Installer C:\Input\Firefox.msi -Destination C:\Output\Firefox -PackageName "Firefox" -Publisher "CN=MyPublisher" -Version 0.0.0.1"
			i. You can play with this and change the Publisher name and Version # if you'd like, but for simplicity-sake, I'm leaving it as-is.
	8.	Enable Sideloading of Unsigned AppX packages:
		a.	Open "Settings" and navigate to 'Update & Security < For Developers < Developer Mode'
		b.	Ensure "Developer Mode" is checked
		c.	This could take a few minutes
	9.	Reboot your system if you haven't already
	10.	Install the new unsigned converted app by registering the "Appxmanifest" file generated by the conversion process
		a.	Open Powershell as Administrator
		b.	Type "cd C:\output\Firefox\Firefox\PackageFiles" followed by 'enter'
		c.	Type "Add-AppxPackage –Register AppxManifest.xml" followed by 'enter' again
	11.	Attempt to run and open Firefox from the Start panel.
	12.	Congrats! Firefox should be successfully built for the Microsoft Store.

I couldn't attach a .ZIP archive copy of the Desktop App Converter output containing a packaged AppX, so I've uploaded it to OneDrive. File can be viewed and downloaded here: https://1drv.ms/f/s!Atsjh-pCpQhZjst2dEIzdFPOoGNaKA

(In reply to jebeld17 from comment #18)

I couldn't attach a .ZIP archive copy of the Desktop App Converter output containing a packaged AppX, so I've uploaded it to OneDrive. File can be viewed and downloaded here: https://1drv.ms/f/s!Atsjh-pCpQhZjst2dEIzdFPOoGNaKA

In the Microsoft Store, applications that use other HTML and JavaScript engines cannot be published.

"Products that browse the web must use the appropriate HTML and JavaScript engines provided by the Windows Platform."

applications that use other HTML and JavaScript engines cannot be published.

Facebook for Windows has been using WebKit for web browsing feature for years, so that's not strictly true.

(In reply to saschanaz from comment #20)

applications that use other HTML and JavaScript engines cannot be published.

Facebook for Windows has been using WebKit for web browsing feature for years, so that's not strictly true.

👍

Attachment #9062732 - Attachment is patch: false
Blocks: 1306911

With recent changes to the Microsoft Store policies, does this mean that a UWP version of Mozilla Firefox is now possible?

Actually, scratch that. UWP is being phased out in favor of the "Windows App SDK" according to Windows Central, so maybe we should focus on converting Mozilla Firefox to that instead: https://www.windowscentral.com/microsoft-publishes-uwp-win32-migration-details

We've been shipping in the Microsoft Store for almost a year now, so this is sortof done, I think? We still can't use certain APIs with the non-Store Firefox, which we have no plans of dropping anytime soon, so maybe we want to keep this open for that reason? (We could get access to those APIs if we added support for sparse packaging to it.)

Do we have a list of such APIs that we are already using?

(In reply to Kagami :saschanaz from comment #24)

Do we have a list of such APIs that we are already using?

I'm not aware of a list, but searching for RuntimeClass on SearchFox is a decent-ish proxy, I think? I wouldn't rely on this as a complete list, but it certainly shows some (eg: SystemMediaTransportControls, ApplicationModel, WindowsIntegrityPolicy).

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: