Firefox/Windows 8 Integration

From MozillaWiki
Jump to: navigation, search

Links

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.

Blockers

We are using the following whiteboard tags to track bugs that block our release with Firefox 28:

  • [beta28] - for bugs that must be fixed before Firefox 28 reaches the beta channel
  • [release28] - for bugs that mut be fixed before Firefox 28 reaches the release channel

Queries:

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

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

Firefox for Windows 8 Builds

Firefox for Windows 8 is currently included in Nightly, Aurora, and Beta builds of Firefox for Windows. It will reach the release channel with Firefox 28 around March 17th, 2014.

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

Browser Crash Reports

Firefox for Metro crash stats

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

  • 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

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

./mach run -metrodesktop

To run in the real "immersive" (full-screen) Metro environment, first launch the desktop browser by typing: 

./mach run

Then press the "Relaunch in Windows 8 Touch" button in the menu to switch to Metro mode. See this support page for details.

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.

Running Desktop and Metro Simultaneously

It's possible to run desktop Firefox and Metro Firefox side-by-side by using different profiles. However, there are some problems caused by the fact that Metro Firefox will only use the default profile (bug 945511), and our startup code will always start in desktop mode if any desktop process is running (bug 945554).

Here's one way to keep desktop Firefox running while testing Metro Firefox in a separate profile:

  1. Create a new profile named "desktop". (You can use Firefox Sync to keep this in sync with your default profile.)
  2. Launch desktop Firefox by running firefox.exe -p desktop -no-remote. (You can create a shortcut to make this more convenient. Instructions for Windows 7+ here)
    • If you are making changes to the Metro Firefox source code, it's useful to start desktop Firefox from separate installation rather than your objdir, so you don't need to close it each time you rebuild.
  3. To launch Metro Firefox, run firefox.exe -no-remote (or ./mach run) and then press the Windows 8 Touch menu button.
    • Or you can launch the Metro UI in a desktop window by running firefox.exe -no-remote -metrodesktop (or ./mach run -metrodesktop).
  4. Use alt-tab or edge/corner gestures to switch between the Metro app and the desktop.

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 run all the tests, run the following mach command in the mozilla-build shell in your mozilla-central source directory: 

./mach mochitest-metro

To run a single test file or directory, 

./mach mochitest-metro path/to/test/file.js

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.

We have a library of convenience functions for use in metro-chrome tests, which you can find in head.js. Note: These tests make heavy use of Promises and Task.jsm.

Building on Linux or Mac OS X

This configuration is not official supported or tested. It might break without anyone noticing for a while. If it doesn't work, let us know and we can help fix it.

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.

JS Console

You can access the JavaScript console by typing Control-Shift-J. You can also set devtools.errorconsole.enabled to "true" in about:config to add an "Open error console" command to the menu button in the navigation bar.

Enable Add-ons

Add-ons are not yet enabled by default in Firefox for Metro, because we have not yet built the UI for users to enable/disable/install/remove add-ons. (We will do this in a future version.) For now, developers and testers can use the following steps to allow Metro Firefox to load add-ons:

  • Open Firefox for Metro.
  • Go to "about:config" and set "extensions.defaultProviders.enabled" to "true".
  • Restart Firefox for Metro.

You can then use Firefox for desktop to install, manage, and remove add-ons. The add-ons that you install in desktop will load in Metro Firefox if they are also marked compatible with the Metro UI. If you are an extension developer, you can make your add-on compatible with Metro Firefox by adding a targetApplication to your install.rdf file with "id" set to {99bceaaa-e3c6-48c1-b981-ef9b46b67d60}. (Metro Firefox will also load extensions with a targetApplication of toolkit@mozilla.org, which are compatible with all XUL applications.)

DOM Inspector

Follow these directions to make the DOM Inspector add-on work in Metro:

  • Follow the steps above to #Enable Add-ons and install DOM Inspector using Firefox for desktop.
  • Add the startDOMi function to /browser/metro/base/content/browser.js.

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 can install it using the steps in #Enable Add-ons above.

  • While in Metro mode, go to about:config and make sure both 'app.crashreporter.prompted' and 'app.crashreporter.autosubmit' preferences are set to false
  • Open the "Settings" charm and choose the "Crash Now" entry. Tap/click it to crash.
  • Restart Metro. You should see the crash dialog as shown here: screenshot

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 Launch Issues

The CEH handles program launch on Windows 8. It's a small win32 program that Explorer launches when the browser is invoked. If issues arise, there are some debugging features built into the program to help diagnose issues.

  • Open regedit.exe and browse to HKEY_CURRENT_USER/Software/Mozilla/Firefox
  • Add a new DWORD value names 'CEHDump', value 01
  • Run a debug output viewer such as DebugView.
  • Launch the browser.

Output from the ceh and launch info from the browser will get dumped to DebugView. You can save this logging info out via the DebugView file menu and post it to bugs for diagnosis.

To turn off debug output for the CEH, change the registry value from 01 to 00, or delete the CEHDump key.

Localized Build

Language Pack extensions are not yet enabled by default in Firefox for Metro, but you can use l10n binary repack method described here to get localized build.

To create localized binary repack for x-testing locale that is based on current sources from Mozilla Central create package locally via Pymake instead of downloading it from Mozilla's ftp servers. 

$ cd ../firefox-build
$ pymake package
$ cd ../firefox-build/browser/locales
$ pymake unpack
$ pymake merge-x-testing LOCALE_MERGEDIR=$(PWD)/mergedir
$ pymake installers-x-testing LOCALE_MERGEDIR=$(PWD)/mergedir

Your localized repack will be available at ../firefox-build/dist folder.

Appropriate l10n sources (to use with --with-l10n-base parameter in .mozconfig) can be downloaded from the following locations:

Please note that you may need to install compare-locale python script to successfully perform merge locale step.

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

See Remotely debugging Firefox for Metro on MDN for instructions.

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. In Windows 8.1 you can use split-screen to keep the desktop and the Metro browser visible at the same time.
  • 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

Using DevTools Profiler

  • Follow all the set up instructions above to get the prefs set right for dev tools / remote debugging.
  • In classic install the profiler extension from: https://github.com/bgirard/Gecko-Profiler-Addon/raw/master/geckoprofiler.xpi
    • Note, by default this extension starts with profiling turned on (for the local build). The toolbar icon will be colored when profiling is active, grayed when off. It's best to keep this extension disabled when not in use.
  • In classic set the pref 'profiler.threads' and 'profiler.stackwalk' to true.
  • Restart classic
  • From the toolbar button dropdown, select TCP, enter the metro browser's ip address, and click connect. You should get a remote connection warning in the metro browser.
  • click the 'analyze' button and wait for the profile view to load. (This may take a while without updating the in tab ui. Give it time.)
  • After you have finishes collecting data, click 'stop' and wait for the button label to update from 'stop' to 'start'.

For additional detail read bug 886555 on getting things going.

For reference: Profiler Wiki.

Profiling Local Builds

Profiles generated using the above config will have os symbols when working with nightly builds on the metro device. For profiling local builds, you'll need to follow these instructions on setting up and configuring a local snappy symbol server.

Example snappy symbol server config: 

[General]
hostname = 127.0.0.1
portNumber = 8000
enableTracing = 1
remoteSymbolServer = http://symbolapi.mozilla.org:80/
maxCacheEntries = 20000000
prefetchInterval = 12
prefetchThreshold = 48
prefetchMaxSymbolsPerLib = 500
defaultApp = Firefox
defaultOs = Windows

[SymbolPaths]
Firefox = T:\Mozilla\MC-REL\dist\crashreporter-symbols\
Windows = T:\Temp

If you run into problems resolving xul symbols, try restarting the symbol server and generating a new profile. Also make sure prefetchMaxSymbolsPerLib in the ini is set to a large value.

Note, for switching back to nightly profiling, set the default symbol server url in classic back to http://symbolapi.mozilla.org/.

Development and Planning Notes

(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.

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.

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).

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 - 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 in-process content (no child processes).
  • 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.

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 - FIXED)
  • 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

Retrieved from "https://wiki.mozilla.org/index.php?title=Firefox/Windows_8_Integration&oldid=932970"