Firefox/Windows 8 Integration

Intro

Microsoft Windows 8 will be the next version of the Windows operating system which is aimed at desktops, laptops, netbooks, tablets, servers, and media center PCs.

A major part of Windows 8 is the introduction of Metro-style applications which are based on the new WinRT APIs. This page will cover both Windows Metro integration and changes for existing Desktop integration.

Access to builds

Everyone doing work in this area should have access to early builds. What’s needed to accomplish this?

• Who controls our MSDN access info?
• What kind of access do we have?
• Do we need to upgrade or get into some sort of a beta program?

Desktop

• Firefox works as it does on other platforms. No major changes to our installer required, although there may be some touchup work to do with registration.

• Firefox receives a tile/icon in Metro when the desktop version is installed. These seem out of place.
  • Potentially we might want to clean this up, or figure out a way for it to not show up assuming we have integrated version of Firefox for Metro.

• 

• Flipping between Metro and the desktop via the firefox icon is a jarring experience. Guessing this experience will be improved, changed.

• In the last release the start menu was removed. Clicking it now takes you to the Metro interface. Another jarring experience which might change.
  • If there is no start menu, what can we skip in the install process?

• It is unclear whether or not there will be Desktop support for ARM. If there is support, there will NOT be an emulation layer like WOW64 for x86 apps.

• Desktop apps do not get suspended when switching to Metro.

• There are taskbar improvements for multi monitor (taskbar spanning)

Metro

• Unlike Desktop, Metro apps will ONLY be available through the Windows store.

• There are no overlapping windows, nor traditional popup windows, everything is chromeless, everything is designed to be consistent across applications.

• Some interprocess communication is possible within Metro, but it is very limited.
  • No electrolysis support?
  • How is IE handling this?

• Not possible to simply and easily port Firefox as a Metro application. A significant amount of Win32 APIs will not be available in Metro.

• A second app can be shown in Metro app with the snap state. It is shown side by side and you can determine the width of each window via a separator.

• The top and bottom edges are for per app toolbars. The left and right edge are reserved for system toolbars (This my require Fennec redesign if we end up using it for Metro).

• You can schedule popup notifications when your Metro app is not running.

Language support

• Based on WinRT APIs, applications can be built in Javascript, C++, C#, or VB.NET
• WinRT is available in each language through the `Windows` namespace

C++

• Compiles to native code but has some extra syntax flare.

HTML and Javascript

• WinJS library provides access to WinRT
• "Chakra" engine uses metadata to generate js/html projections of WinRT objects dynamically

API Spec

• Win32 & COM support Link
• Windows Runtime (WinRT) Link
• General WinRT overview and porting guide Link

Sandboxing

• File access
• Registry access
• Networking

Graphics

• Subset of Direct2D, Direct3D, DirectWrite drawing apis supported. Link

Networking

• Win32 WS* APIs Link
• WinRT Networking Link

Suspend/resume

• Most of this info comes from this video on Metro app suspension
• There is no multi-tasking of Metro apps: Only one app runs unsuspended at a time, apps are suspended when not in foreground
• Desktop is treated as one app; all other Metro apps are suspended when desktop is active
• Upon suspension, app gets notification that it is being suspended
  • At this point, app must save state because it could be terminated later without notice
  • App gets 5s to handle suspend, otherwise crashes
• During suspension
  • App is not scheduled by the NT kernel
  • No CPU, Disk, Network consumption
  • All threads suspended
  • App remains in memory
• App is instantly resumed when brought to foreground
• Suspension best practices:
  • Save state quickly (<5s)
  • Assume you will be terminated: Save user session data
  • Update app's tile
  • Release exclusive access to shared resources (files, devices, network, etc)
  • Save app data incrementally before suspend

Registering callbacks for suspend and resume (JS)

//Register for the Suspending event and call suspendingHandler when received
Windows.UI.WebUI.WebUIApplication.addEventListener("suspending", suspendingHandler); 

//Handle the suspending event and save the current user sesssion using WinJS sessionState
function suspendingHandler(eventArgs) {
  //We are getting suspended
}

//Register for the Resuming event and call resumingHandler when received
Windows.UI.WebUI.WebUIApplication.addEventListener("resuming", resumingHandler);

function resumingHandler() {
  //We are getting resumed, in general do nothing
}

Live tiles

• Apps that have tiles implement the `Windows.Launch` contract
• Tile is specified by an XML file that follows a template (limited number of templates provided by Windows?)
• Tile (XML) can be updated while app is running
• Tile can be updated using push notifications
  • Push new tile XML to a URI provided by "Windows Push Notification Service" (WNS)
  • WNS pushes tile to user's device

Contracts

• There is a new concept called contracts for interconnection/sharing with different metro apps.
• Implementing contracts provides more integration with the OS (e.g. with the "charms" toolbar)
• Known contracts are:
  • Windows.BackgroundTasks
  • Windows.File
  • Windows.FilePicker
  • Windows.Launch - Apps that implement this get a tile in the Windows 8 Metro "desktop"
  • Windows.Protocol
  • Windows.Search
  • Windows.ShareTarget
• Information about which apps fulfill each contract is maintained in the registry
  • HKCU\Software\Classes\Extensions\ContractId
  • One key for each type of contract, subkeys are registrations for all extensions that implement that contract
• Apps can be activated through the contracts they implement
  • Event args provide context

Activation Example (JS)

//Register handler for activation event
Windows.UI.WebUI.WebUIApplication.addEventListener("activated", activatedHandler);

function activatedHandler(eventArgs) {
  if (eventArgs.kind == Windows.ApplicationModel.Activation.ActivationKind.launch) {
    //Tile activation initialization logic here
  }
  else if (eventArgs.kind == Windows.ApplicationModel.Activation.ActivationKind.shareTarget) {
    //Share activation initialization logic here
  }
  //etc...
}

Fennec & Metro interface comparisons

• Generally the two are not currently compatible. Controls on the left and right (Fennec) vs. top/bottom for Metro
• Pop down address bar vs our "scroll to top controls" approach
• Look and feel differences, new theme?

IE 10 Metro w/desktop sidebar

Windows Store

• installer?
• Restrictions on content?
• Big question: would we have licensing issues similar to iOS ports?

Misc.

• Process control
• Async APIs
• TSF support needed / required?

Porting Gecko

• Different approaches discussed
  • Faking Metro support via the desktop
  • Interprocess solutions – piping the gecko UI into a metro shim
  • Porting Gecko / Native Metro browser
• We rely heavily on the Win32 API (import list) much of which is not available.
• Storage: Is SQLite portable?
• Graphics: do we have what we need in DirectX to do a port?
• NSPR: may be a real PITA to port.
  • Network isolation guidelines Link
• Installing via the Windows Store uses a new packaging mechanism.

Links

• Building Offline Experiences with HTML5 AppCache and IndexedDB
• Lap around the Windows Runtime
• Windows Runtime internals
• Bug 686835 - Windows 8 / Metro Support
• Building on/for Windows 8
• API for Metro style apps
• ARM support
• lack of inter-process communication support
• Reusing some existing code