Firefox/Windows 8 Integration

Wiki

• Metro Project - meeting times, bug lists, project goals, team info, etc.
• General Firefox Product Feature Tracking - Firefox feature tracking.
• Firefox Metro UI wiki - including comp work and UX bug tracking.
• Metro Project Status - not really in use.
• Windows_8_Integration - General 3rd party browser collaboration page dedicated to overview, architecture, and challenges for vendors. Early research with Google.
• Windows 8 (desktop)
• Firefox/Windows 8 Metro Style Guides - coding standards and UI guidelines

Useful Bugzilla Queries

Win8 Metro

• Metro Firefox complete list

Win8 Metro

• Metro Firefox complete list
• Minus feature=story, epic, and MetroV1

Untagged Bugs

• Not blocked by various pm triage tracking bugs
• Whiteboard does not contain feature=epic, work, change, defect, story
• Summary does not contain 'MetroV1'

Last three days

• Bugs filed against product Metro Firefox in the last three days

Platform

• Core, Toolkit, mozilla.org

Getting Involved

Contact Brian Bondy with questions (bbondy on IRC). The Windows 8 integration team can be found in in #windev.

Bugzilla

Please file front end bugs under the product Firefox for Metro. Back end bugs should be filed in the appropriate Platform component.

Front End Windows 8 Development

• To contribute to front end bugs, you will use: JS, CSS, XUL, XBL
• You do not actually need Windows 8 to work on the front end code
• Follow the steps in the Metro Builds section below to get setup
• The front end code is located in browser/metro
• Style guidelines of all types can be found on https://wiki.mozilla.org/Firefox/Windows_8_Metro_Style_Guides
• the front end code is to be literally a user friendly. it helps developers to get understood easily.

Platform Integration Windows 8 Development

• To contribute to platform integration bugs, you will use: C++
• You do need Windows 8 to work on the platform integration code
• You can obtain a 90 day free Windows 8 evaluation for developers from Microsoft
• Follow the steps in the Metro Builds section below to get setup
• The platform integration code is located in widget/windows/winrt
• You can find Windows 8 platform integration bugs here http://goo.gl/B0Xjo or by doing an advanced bugzilla search for: OS = Windows 8 Metro, Product = Core, Component = Widget: Win32

Metro Builds

Nightly Builds

Update: 6/24/2013

Nightly builds are now being generated on mozilla-central.

Nightly builds off the mozilla-central repository are currently available in the Firefox build archives.

To set these builds up:

• Install the browser using the latest installer
• Open the desktop browser - when the default browser check occurs, select yes to set Firefox as the default. You should also receive a Windows prompt, select Nightly. This will associate Firefox with various protocol handlers and create the Firefox tile.
• To set file handler associations use Window's Control Panel for default program associations. (Options -> Advanced -> General and click the default browser button at the bottom to open this panel.)

For more detailed help on installing / setting the browser as the default, visit the Metro Firefox support page.

Nightly Crash Reports

Firefox for Metro

Switching Default Browsers

This can be a little tedious when working with multiple builds / installs on a single device. Steps:

• Close Firefox both in Metro and on Desktop
• Open Control Panel's default programs and set IE as the default
• With debug builds: run the resulting firefox.exe on the desktop and set as the default through Options menu -> Advanced -> General tab -> Make default button.
• For release builds: run the resulting firefox.exe on the desktop and click yes to the default settings dialog, then select 'Nightly' in the Windows 8 prompt.
• In Control Panel's default programs, set firefox as the default browser.

To confirm the right browser is set, launch the browser in Metro, switch to desktop, open task manager, right-click the Firefox process, and select open file location.

Note pinned taskbar shortcuts can't be trusted to open the right browser.

Zip Builds

Zip installs from daily checkins are currently available on the Firefox build archives.

To install:

• Download the newest firefox-(rev).0a1.en-US.win32.zip to your Win8 device
• Unpack the main firefox folder to a suitable location
• Run firefox.exe on the desktop
• If prompted by Windows, select Nightly/Aurora/Firefox as the default.
• Open Options -> Advanced -> General and click the "Make Firefox the default browser" button. This will open Windows Control Panel where you will need to select the channel build you are testing and set the defaults.

Building Locally

Updated 5/21/2013

• Install Visual Studio 2010 or 2012.
• Install MozillaBuild (version 1.7 required)
• Install the Windows 8.0 SDK
• Install DirectX SDK (June 2010)

• For VC 2010 builds:
  • Modify the the following header in the sdk:

C:\Program Files (x86)\Windows Kits\8.0\Include\winrt\asyncinfo.h

line 67:

enum class AsyncStatus {

to

enum /*class*/ AsyncStatus {

If you use both VC 2010 and VC 2012 (or plan to install VC 2012 in the near future) you might want to instead use the following patch, which reverts to the original code under VC 2012 and later:

--- asyncinfo.h.orig	2013-05-21 08:47:49 -0400
+++ asyncinfo.h	2013-05-21 08:48:55 -0400
@@ -58,17 +58,21 @@
 /* interface __MIDL_itf_asyncinfo_0000_0000 */
 /* [local] */ 
 
 //  Microsoft Windows
 //  Copyright (c) Microsoft Corporation. All rights reserved.
 #pragma once
 #ifdef __cplusplus
 namespace ABI { namespace Windows { namespace Foundation {
+#if defined (_MSC_VER) && _MSC_VER >= 1700
 enum class AsyncStatus {
+#else
+enum AsyncStatus {
+#endif
   Started = 0,
   Completed, 
   Canceled, 
   Error,
 };
 } } } // ABI::Windows:::Foundation
 using ABI::Windows::Foundation::AsyncStatus;
 #ifndef _HIDE_GLOBAL_ASYNC_STATUS

• For Express versions of VS:
  • Install the Windows Driver Toolkit, version 7.1.0 - Version 7.1.0 is needed because it contains the necessary ATL headers that express VS lacks.
  • Add the following to start-msvc*.bat file near the end just before the line that reads cd "%USERPROFILE%" (assumes WinDDK was installed in "C:\WinDDK\7600.16385.1"):

set "INCLUDE=C:\WinDDK\7600.16385.1\inc\atl71;%INCLUDE%"
set "LIB=C:\WinDDK\7600.16385.1\lib\ATL\i386;%LIB%"

• Check out mozilla-central. Make sure the obj directory has "Modify" permissions given to the current user.
• Create a standard browser .mozconfig file with the options you prefer and add

ac_add_options --enable-metro

• Build Firefox.

At this point, you should be able to launch the metro browser on the desktop using a command line switch:

(obj)/dist/bin/firefox.exe -metrodesktop

To register local builds as the default browser:

• For debug builds: run the resulting firefox.exe on the desktop and set as the default through Options menu -> Advanced -> General tab -> Make default button.
• For release builds: run the resulting firefox.exe on the desktop and click yes to the default settings dialog, then select 'Nightly' in the Windows 8 prompt.
• Open up Control Panel -> Default Programs. You should see 'Metro Firefox' in the list of applications.
• Set all Metro Firefox defaults in Default Programs.

At which point you should have a Firefox tile in Win8 that launches the browser.

Note, for debug builds, see Firefox/Windows_8_Integration#Logging_Assertions.

Desktop Launch

To launch within the metro experience follow the registration steps above. To launch the metro front end UI using the win32 widget backend on the desktop (including non-Windows-8 devices) use the -metrodesktop command line option:

(path to firefox build)/firefox.exe -metrodesktop

To set things up such that you can test touch input on the desktop - flip the 'metro.debug.treatmouseastouch' to true in /browser/metro/profile/metro.js.

Note on the desktop we use the desktop's Win32/Widget backend. This can behave differently from the Win8 WinRT backend. The translational layer for Win32 events is location in /browser/metro/content/base/input.js.

Testing

Browser-chrome tests for Metro Firefox are located in browser/metro/base/tests. The tests run in the Metro environment; Windows 8 is required.

Currently, some of the selection tests may fail (specifically, browser_selection_frame_textarea.js) if the device and CSS pixels are out of sync. To solve this, you may need to change the following pref in about:config to the following value.

layout.css.devPixelsPerPx = 1.0 (default is -1.0, which makes Firefox autoscale CSS pixels)

To start the tests, run the following command in the mozilla-build shell, at the top level of your obj-dir:

pymake mochitest-metro-chrome

The Metro browser will launch, run the tests and exit. Any failures will be printed to the console. The complete test log will be written to the file mochitest-metro-chrome.log in the objdir.

Building on Linux or Mac OS X

You can use the --enable-metro configure option and the -metrodesktop command-line flag to build and run the Metro UI on other platforms too. For details, see Metro Firefox without Windows 8.

On Mac, you might need to run "./mach build browser" after your build completes. For details, see bug 847807.

• there is a problem with html5 EMBED tag. an EMBED tag is basically to play media files. but we can't use this on mac.

Logging Assertions

When you're running Metro Firefox with --enable-debug, there will be assertion failure messages that show up in the console. The following environment variable is assumed for the Metro environment:

XPCOM_DEBUG_BREAK=warn

Remote Debug Output

NSPR logging can be dumped to OutputDebugString using the NSPR_LOG_FILE environment variable:

NSPR_LOG_FILE=WinDebug

To log NS assertions and warnings in debug builds add the nsDebug log module:

NSPR_LOG_MODULES=nsDebug:4

bug 762519 was filed on getting javascript's dump output going to OutputDebugString as well.

DOM Inspector

Getting DOM Inspector attached to builds running on the desktop takes a few tweaks.

• Install the dom inspector addon (if you do not have it already) on your desktop firefox
• Copy the '[email protected]' folder under your Firefox profile's extension directory over to your MetroFirefox profile extensions directory. (Example: C:\Users\Brian\AppData\Roaming\Mozilla\MetroFirefox\Profiles\amrcb8eg.default\extensions)
• add an entry in inspector's install.rdf file for metrofx and make sure the maxVersion is set correctly.

<em:targetApplication>
  <Description>
    <em:id>{99bceaaa-e3c6-48c1-b981-ef9b46b67d60}</em:id>
    <em:minVersion>1.0a1</em:minVersion>
    <em:maxVersion>19.0a1</em:maxVersion>
  </Description>
</em:targetApplication>

• Add the startDOMi function to /browser/metro/base/content/browser.js.
• Add a call to startDOMi() below the BrowserUI.init() call.
  • If you start the browser and see a blank screen with your patch containing startDOMi() applied, it probably means the extension hasn't been enabled/installed properly. Often its the last step of flipping values.
• Tweak the following extension prefs in metro.js:

pref("extensions.autoDisableScopes", 15);
pref("extensions.minCompatibleAppVersion", "4.0");
pref("extensions.strictCompatibility", false);

• The extensions.json file will be created the first time MetroFirefox is run and discovers the [email protected] extension content in the profile, but you have to flip a couple of values to make it actually work. Set the 'active' property to boolean true and the userDisabled property to boolean false.

Venkman Debugger

(10/5/12 - Note, since we've changed the app id, this probably doesn't work.)

• Copy the '{f13b157f-b174-47e7-a34d-4815ddfdfeb8}' xpi under your Firefox profile's extension directory over to your MetroFirefox profile extensions directory.

• Launch the browser with the '-venkman' command line option.

JS Shell

For debugging the ede js shell and javascript console are available on the app bar in desktop builds.

Crash Testing

To test the Crash Reporter UI and other crash-related behavior, you can make use of install the Crash Me addon (sources are on Google Code.) This extension is already Metro Firefox ready, so you just need to follow similar steps as for the DOM Inspector to enable it.

• Install the Crash Me addon (if you do not have it already) on your desktop firefox
• Copy the '[email protected]' folder under your Firefox profile's extension directory over to your MetroFirefox profile extensions directory. (Example: C:\Users\Brian\AppData\Roaming\Mozilla\MetroFirefox\Profiles\amrcb8eg.default\extensions)
• - OR - you can just download and unzip the .xpi file into a [email protected] folder in your profile extensions directory
• To allow discovery and install of add-ons, set extensions.autoDisableScopes to 15, either via your local metro.js or in about:config
• If you are using a local build, you may need to edit the metroapp.ini (generated from the metroapp.ini.in template) to ensure the Crash Reporter Enabled=1 flag is set.

To use, you'll find a new "Crash Now!" entry in the Settings charm. Tap it to crash.

WinRT Compiler Generated Code

Compiler switches:

• /d1ZWtokens - dump C++ code generated code for C++/CX.
• /d1reportAllClassLayout - dump class layouts
• /d1reportSingleClassLayoutXXX - where XXX performs substring matches against the class name.

Remote Debugging with a VM

(This was last tested with the Win8 RP)

Setup steps -

• create a new drive for vm, clone src there, build. obj dir should also be on this drive.
• Enable sharing on the drive, set permissions to full access
• On workstation, map vm share to a local drive. Use the same drive letter for both the vm drive and the mapped workstation drive!
• config vm’s metro firefox as the default Metro browser
• on vm, start – ‘debug’ should bring up remote debug tools folder – run the x64 version if on 64 bit os, x86 otherwise
• start remote debugger on vm
• create empty remote debugging project on workstation
• in project set debug settings:
  • Remote command: (common letter drive):\(path to obj dir)\dist\bin\firefox.exe
  • Working dir – same
  • Remove Server Name: vm network name w/ port
  • Attach: Yes
• Launch browser in vm
• F5 in project on workstation

That should be it. OutputDebugString output will land in the workstation debugger console. Breaking in the debugger doesn't kill the browser as long as metro is active and the browser is running in the foreground.

Note – AFAICT, you can’t reverse the relationship here. Metro will not launch a default browser located on a mapped drive that points to an obj dir on workstation. If we could fine a way around this it would be great.

Remote Debugging with a Tablet

Setup steps -

• In Explorer on the tablet purge any unused space on C, including old Windows installation files, using the system file cleanup option under the drive's properties panel.
• From Control Panel, bring up the disk manager and split the main disk partition into two. A 20GB partition for mozilla related bits is suitable.
• Format the second partition and designate a drive letter for it. Use a drive letter your debugging workstation does not use.
• Right-click the new mozilla drive in Explorer and select Share. Share the volume using your login credentials or you can also openly share to "Everyone" if your local network is secure. Set permissions on the share to full access.
• On your main workstation browse to the tablet share and map it to a local drive using the same drive letter you used for the tablet drive. This insures object source has the same path info on both machines.
• Install Visual Studio and mozilla-build on the tablet.
• Checkout mozilla-central on the mozilla partition of the tablet, then build and register the browser.
• On the tablet, Start + ‘debug’ should bring up a remote debug tools folder via search, open this and launch the remote debug monitor. Run the x64 version if on 64 bit os, x86 otherwise. (Pin this to your start menu for easy access.)
• Under the monitor's tools menu, add permission for your login credentials or "Everyone" for remote debugging.
• On the workstation, create a blank C++ debugging project for the tablet, set debug settings as follows:
  • Remote command: (common letter drive):\(path to obj dir)\dist\bin\firefox.exe
  • Working dir – same
  • Remove Server Name: Tablet network name w/ port. The remote debugging tools window on the tablet can provide this.
  • Attach: Yes

After this you should be able to launch the browser on the tablet and attach to it from Visual Studio on your workstation. You should also be able to browse source on the networked drive, set break points, etc., just like a local debug session. Most debug output the browser spits out should be transferred over to the remote debugger.

Note you might have to fiddle with access permissions a bit. Opening everything up to Everyone saves a lot of time, but might not be the most secure environment, depending on your situation.

Diagnosing Startup Problems

Due to the embedded nature of metro browsers, diagnosing startup problems can be a bit of a pain. There are a few things you can do to help devs figure out what's going wrong.

1) Launch the metro browser interface on desktop to confirm the install is working.

• Navigate to firefox's install location in explorer
• Hold shift, right-click the folder with firefox.exe and select open command prompt.
• in the prompt type 'firefox.exe -metrodesktop'

The metro front end should launch in a window on the desktop. If not, try uninstalling and re-installing. If that doesn't help, please file a bug.

2) Check Direct3D start up check results

Using regedit.exe, check under the following key for a value named 'MetroD3DAvailable':

HKEY_CURRENT_USER\SOFTWARE\Mozilla\Firefox

If the value is 0, Direct3D startup checks failed. Please file a bug, and post the Graphics section of your desktop browser's about:support section to the bug. If there is no value, please file a bug. If the value is 1, startup checks succeeded.

3) Check for submitted crashes reports

To check if metro fx is generating and submitting crash reports open explorer to the following path:

C:\Users\(youraccount)\AppData\Roaming\Mozilla\MetroFirefox\Crash Reports\submitted\

If the folder exists and contains text files please file a bug and copy the contents of a few of the most recent files into the bug.

4) Check for unsubmitted crashes reports

Metro firefox can not submit crashes for analysis unless the browser fully starts (bug 797023).

To check if metro fx is crashing on startup, open explorer to the following path:

C:\Users\(youraccount)\AppData\Roaming\Mozilla\MetroFirefox\Crash Reports\

In this folder look for two files:

LastCrash lastCrashFilename

If both files are present, delete them, and try restarting Metro Firefox again. After doing this, check the folder again. If the files return, a startup crash is likely.

There are two things you can do t this point to help diagnose the problem:

Option 1: Use Desktop Firefox to submit the crash report to Mozilla's crash server -

• open lastCrashFilename with notepad.exe
• copy the temp path and note the file name of the crash report
• open the temp path in explorer and locate the two files associated with the report.

There will be two files, both will have the same file name (a uuid string) and the extensions .dmp and .extra.

• shutdown desktop firefox if it is running
• In explorer, copy both files from their location into the follow folder:

C:\Users\(youraccount)\AppData\Roaming\Mozilla\Firefox\Crash Reports\pending\

• start Desktop Firefox.
• Navigate to 'about:crashes'.
• find the uuid of the report you copied and click on its link

If the link does not resolve to a crash server crash report immediately, wait a few minutes and try again. Once the link resolves, file a bug and copy the report's link into the bug report.

Option 2:

File a bug and contact a dev. who you can share your crash report with. Note crash reports can contain user specific info, do not submit these files to bugzilla as attachments.

4) Logging startup

..

5) CEH logging

..

Testing Harness

Builds generate a test harness (dist/bin/metrotestharness.exe) that can be used to launch the metro browser into the immersive environment. This harness is also packed up with the test zips used in automation testing.

Metro Firefox can't accept standard command line parameters since it must be launched by Windows. The harness acts as a pass through for mozilla command line parameters firefox.exe can accept. Incoming params are written out to an ini file @ dist/bin and read in via nsBrowserApp when the browser starts up.

By default the test harness assumes the default browser (firefox.exe) is in the same folder metrotestharness.exe is located. If you want to launch the default browser at a different location from metrotestharness.exe, you must specify a firefox path using -firefoxpath (fullpath):

metrotestharness.exe -firefoxpath T:\Mozilla\objmcrel\dist\bin\ -url www.mozilla.org

The test harness will need *write* permission to this location to write out a command line arg ini file.

harness source

Using Devtools

• Tracking bug https://bugzilla.mozilla.org/show_bug.cgi?id=850019
  • There are known issues with the profiler. All other parts should be functional, modulo the refactoring work the devtools team is doing on them.
• This hooks into the tools developed & maintained by the devtools team.
• They have been refactoring & improving their tools, so it highly encouraged to use Nightly builds on both sides of the pairing if possible.

• Before you start
  • You must have metro installed & working
  • You must access to a classic/desktop fx. This need not be a local build
  • If you are connecting remotely, you must make sure both machines can ping each other before starting. This will save you a lot of grief later
    • on windows ipconfig in the cmdline is helpful in getting your ip address
    • on windows 8 this usually means disabling the firewall (not encouraged) or adding inbound/outbound firewall rules to allow them to connect.
      • If you need it, Peter in IT now knows a fair bit about setting up those rules if you get lost or stuck.
  • If you are on wifi, both devices must be on the same network to communicate. Mozilla != Mozilla-G.
    • It sounds silly but some of the windows devices only see Mozilla-G and the older company issued thinkpads do not have the hardware for it.

• Setup
  • Go to about:config on classic/desktop fx
    • devtools.debugger.force-local -> false
    • devtools.debugger.remote-enabled -> true
    • Check that these values are what you want
      • devtools.debugger.remote-port -> 6000 (I'd leave this one alone unless you have a compelling reason to change it)
    • If you don't have these, you'll probably want these as well
      • devtools.debugger.log -> true
      • browser.dom.window.dump.enabled -> true
  • Restart classic/desktop fx
    • You need to restart for the next step to work.
  • Navigate Firefox button -> Web Developer -> "Connect.." entry between the Error Console" & "Get More Tools" Entry
    • https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Debugging/Setting_up is what this step is based on
  • Go to about:config on metrofx
    • devtools.debugger.force-local -> false
    • devtools.debugger.remote-enabled -> true
    • and you may want
      • devtools.debugger.log -> true
      • devtools.errorconsole.enabled -> true
      • browser.dom.window.dump.enabled -> true
    • devtools.debugger.remote-port -> 6000 (again I'd leave this one alone)
    • It is unclear if a restart is required. I frequently do in the test-build-dev cycle anyway.
  • Make sure metrofx is started (and not suspended)
  • In classic fx, click the "Connect..." entry
    • Depending on your version, this will launch a new tab or a new panel on firefox
    • Enter the ip of metrofx if you are connecting remotely and the port number if you've changed them.
    • If you are connecting on a localhost, you shouldn't need to change the default settings.
  • Click the connect button in classic fx
  • On metrofx a strap(the metro version of the modal dialog) will appear about an incoming connection.
    • Click/tap "allow"
  • On classic fx, the connect page will reload with a list of active tabs & processes. Usually 'main process' is the most interesting.
  • The devtools console will appear & the aforementioned tab on classic fx will disappear
  • Sally forth & debug!

• Notes
  • I usually pair on localhost, using an external monitor so I can see metrofx & classicfx at the same time.
  • If you are using localhost without an external monitor, beware of windows suspending the metrofx while its waiting for the incoming connection. This will cause the pairing to fail.
  • While you can pair classic/metrofx running out of the same obj dir, I frequently experienced unexpected hangs and crashes as a result.
  • if you close the devtools window, this usually results in the metro browser shutting down

Samsung Series 7

The Series seven is the first device we started developing with. Details below on getting the hardware set up with Windows 8.

• To order, file a bug under mozilla.org, Server Operations: Desktop Issues. See bug 738613, CC your PM or Asa.

• Once you have the tablet, dock, and keyboard, unpack. Charge up the device. It'll be running Win7, ignore all the default software.

• Download the 64-bit (3.6 gig) Win8 ISO from \\fs2\IT\Microsoft. Add your name to the list of people who will need product keys in bug 783811. Burn the ISO to a suitable memory stick. For burning on Windows you'll need to download and install the Windows 7 USB DVD Download Tool from Microsoft. For burning on mac?

• Once you have the ISO burned, plug the USB stick into the tablet's dock. Browse to the USB drive and run "setup.exe". When prompted choose that you want to save nothing from the previous install.

• Samsung provides an instruction manual on hooking up the Bluetooth keyboard. You can do this after you've installed Win8 as the Win7 desktop instructions are applicable on Win8 desktop.

• After the tablet is set up, download Firefox nightly or build a local copy and start debugging!

Firmware Updates

For more precise touch input, especially with tap and hold, install the "Touch Screen Sensor Firmware Configuration Updater Tool". Updating the system bios from 7 to 10 doesn't hurt either. Make sure to reboot the system after the install.

Samsung Link

Samsung Series 7 Tweaks

• To fix auto changing brightness problems for wipe Win8 installs:
  • Open desktop
  • click/tap on the battery icon in the taskbar, select "More power options"
  • Select your current power plan or create a new plan via the link on the left.
  • Under the power plan select "Change advanced power settings"
  • scroll down to "Display" and expand
  • Find the sub-option "Enable adaptive brightness" and expand
  • disable both options under this sub-option

Metro Planning

(Older content from the original planning stage)

This is summary of our work / planning for a Win8 Metro browser. For testing purposes we have been working with the /mobile/xul Fennec browser. Moving forward we would like to take the base Fennec XUL code and Metro specific code we've already developed (currently on Elm with some build related work already on mc) and integrate this in with the default Firefox build and install.

We are interested in getting as much feedback as possible from stake holders and from people who have worked with these newer platforms. If you have Win8 up and running in a vm or on a test system, there are details here on how to get builds going, how to register the browser, and test builds for installing.

• Metro specific bug list
• Developing Metro Style Enabled Desktop Browsers

What’s different and what’s the same

By in large platform was a nice fit for Metro. We ran into surprisingly few problems. It took us about a week to get a basic version of Fennec running in the environment and most of that time was spent combing through the registration/integration doc Microsoft sent us. Below are some specific details on the areas of the repo we are currently leveraging.

nsBrowserApp

Currently using fennec’s nsBrowserApp.

chrome interface markup and css (different)

Metro apps are single window applications. The current desktop UI does not fit this new environment. There are no secondary windows we create. Secondary UI (file pickers, warnings, message boxes, toasts) are all displayed and managed by the os. The interfaces to these features are also async. We will provide interfaces for invoking these. Some have already been integrated on Elm (file picker for example).

browser comps (different)

dictionaries, hyphenation, res, searchplugins, extensions, plugins (shared)

Due to the differences in view model most of /browser components code can’t be leveraged. Fennec's script based components are currently in use. [1]

The current metro browser leverages the Fennec front end app code but we could switch to firefox’s code base and enable / augment what we need for metro.

toolkit/xre (modest differences)

The app model is slightly different for Metro. UI events and rendering do not occur on the main thread. We have a working model implemented on Elm that breaks up parts of XRE_main so that certain parts (startup & run) can be called on a different ‘main’ thread.

widget (mostly shared widget/windows code base with different nsIWidget classes)

There are significant differences in the view model so we needed a new nsWindow class. nsWindow latches into a new set of apis for events and view management. [2] Generally winrt and winapi code has integrated well together. We are currently leveraging Component Extensions and various winrt runtime classes. We will be able to share a great deal of win32 widget code.

default browser integration (new registration / launch characteristics for both desktop and metro for win8, older os remains unchanged)

installer/helper/uninstall (shared codebase w/new registration for win8)

On Windows8 the mechanics of launching the browser have changed. There is a new intermediary (a ‘command execute handler’) which is a small, light weight COM server Windows launches. This application chooses which browser to launch based on the environment requested. This change effects the launch of both browsers and the way we register as the default browser on Windows 8. [3] We currently have a basic Fennec install going for testing purposes, but it shouldn’t be too hard to move this over to the Firefox installer.

everything else in runtime (shared)

Generally we’re currently leveraging a majority of our common code base without issue. Threading, timers, networking, ssl, layout, gfx, etc. have all fit in really well. Misc. detail -

• gfx - not currently using accelerated layers but plan to in the near future. The surface rendered to in Metro is D2D and there is no GDI fallback. As such there are some issues with blacklisted hardware.
• e10s - currently using Fennec’s out of process tabs.
• Accessibility - not integrated yet.
• Netwerk - no issues.
• Layout - no issues.
• dom & dom/system & hal - DOM interfaces for device info / sensor input and events. Currently there isn't much here for Windows.
• media - no issues.
• storage - works, although there are some profile corruption problems from early termination which can occur in metro. We also have a 'shared profile' problem (see Big Issues).
• toolkit - very little of this is in use. Crash reporter UI will need work/integration.
• xpcom - no issues.

A tentative proposal

• Copy mobile/xul code down to browser level in /browser/metro.
• Integrate metro startup into firefox's nsBrowserApp bug 747347.
• Integrate building this new area into the current desktop firefox build. bug 747347
• Fixup the firefox installer so that we bring both browsers down in a single unified windows install. bug 737833
• Share the runtime between the two apps in the install. [completed]
• Have nsBrowserApp communicate to xul lib what environment we are running in. [completed]
• Dynamically switch out which code path we want in xul lib where necessary. [completed]
• Organize dist interface code and browser comps such that desktop firefox install layout remains unchanged. Layer metro specific resources down in such a way that the two sets of resources do not conflict. bug 755724
• Share a single profile between both browsers or Sync two profiles on the same machine.

Elm to mozilla-central migration tracking bug: bug 747347

Pros and Cons

• Pro – single unified Windows installer / unified browser build.
• Pro – shared runtime without multiple copies of key files like xul.dll.

• Con – larger Windows install regardless of what version of the os we install on. metrobrowser would be present on all Windows installs.
• Con – builders / release eng. will have to upgrade to VC11 / Win8 SDK to do the build. For the time being however we have a build switch that enables win8 specific components, so we can start landing on mc without breaking existing desktop builds which leverage vc10 build tools. bug 737994

• Pro/Con – With this setup we currently assume we will leverage xul lib. On the positive side having xul makes putting together our UI fast and easy. On the negative side startup performance may be an issue. We are working on getting telemetry data going so we can better measure this in the test builds we are distributing. Thus far test builds we have going on Samsung tablets and a few other test machines show promise on startup performance. Windows is obviously optimized for loading our libraries and the browsers we compete against all have the same encumbrance.

Big Issues

• Windows XP - The current VC11 Beta redist runtime is not compatible with XP. (bug 744942)
• Profiles – Certain areas of the user’s profile will need to be shared between two concurrently running browser apps. We’ve just begun exploring ways to do this. Potential solution might involve a mysql database connection shim that leverages a profile broker and IPC so both browsers can talk to the same profile. We also might consider using Sync. There are some hurdles here to overcome. [A decision was made to use Sync initially.]
• Accessibility - This area of the code base will be in heavy use in the Metro environment with touch interfaces. Our accessibility code will require performance work and may require a new UI Automation adapter since Win8 leverages UI Automation exclusively.
• e10s - (khuey) Certain things are pretty much broken in e10s (e.g. IndexedDB) and other features have not received any testing in several months. Relying on e10s will likely require some investment in the platform to clean this up for metro/desktop parity. Not relying on e10s may decrease the amount of existing XUL Fennec code that can be reused. [question: (jimm) what's the difference in the amount of work we have to do? We've disabled remote tabs on elm for now to see what's broken.] [A decision was made to use in-process content for the foreseeable future.]
• Extensions - currently extension support will be off until a suitable extension mechanism can be designed and implemented.

Links

• API for Metro style apps
• ARM support