Canmove, confirm
2,056
edits
Changes
reorganize into high-level buckets
* P1 for Q1 2012: Android
* P2 for Q1 2012: Windows Classic (XP+)
* P1 for Q3 2012: Windows Metro
= Performance and Resource Goals = Product Requirements ==
* Native widget support, especially toolbar, menu, list?, scrolling canvas?
* Device APIs
* Silent update of the runtime
=== Expected User Interactions ===
==== Android: ====
The user installs a Mozilla Marketplace application from the Android Marketplace, granting access to a superset of device APIs allowed to Mozilla apps. The user then clicks an Install button from inside this application. The Marketplace application may then initiate a background task to download the resources associated with the application, not signalling readiness until the download task is complete. A new shortcut is created on their launcher screen. When the user launches the shortcut, the application launches full-screen with instant access to the downloaded resources.
* cjones: silent update of runtime may not be possible; also, if we want Firefox to share profile with WebRT it has to be in the same .apk (q: not just the same signing key?)
==== Windows, Classic, non-Firefox user: ====
The user navigates to a Mozilla-powered marketplace website using Internet Explorer or another browser. The user clicks an Install button on the website. This causes an executable to be downloaded, in the usual Windows installer experience. The executable is installed with the usual Start Menu / Desktop options. This little executable is responsible for making sure WebRT is available on the system, if needed, and for launching the app.
* cjones: to support Windows uninstall behavior, we need a full install step, branding, etc.
==== Windows, Classic, Firefox user: ====
The user navigates to a Mozilla-powered marketplace using Firefox. The user clicks an Install button on the website. Firefox prompts the user for the usual Start Menu / Desktop Windows install options, and creates an executable in the user's file system. When the user launches the executable, it links against the WebRT libraries provided by Firefox and launches with normal Windows behavior. The Firefox silent update process may be responsible for keeping the WebRT libraries up-to-date.
==== Windows Metro User ====
TBW
= Features == Native Integration ===
==== Android ==== Native integration with Android comprises the following features: * icon on homescreen: an launcher icon on the user's homescreen that can be repositioned and removed like those for native apps and that launches the app when tapped* installed apps entry: an entry in the platform's list of installed apps* task switcher entry: an entry in the platform's list of running apps while the app is running* multitasking: the ability for more than one app to run simultaneously* data sandboxing: platform-level isolation of each app's data* native uninstall: the ability to uninstall in app using native affordances* native major updates: the native UX flow for updating an app when the app makes changes that require user confirmation (f.e. to permissions)* native permissions: reflection of the app's permissions into the native interface for browsing app permissions* known source: apps are seen as being from a "known source", so they do not trigger the default prohibition on the installation of apps from "unknown sources"* graceful offline behavior: ?* full screen/chromeless: ?* instant on: ? === Features === ==== Stub Executable Creation ====
The WebRT stub executable is a platform-specific executable that is responsible for downloading the WebRT library (if necessary), initiating self-update (if necessary), and for instantiating the WebRT libraries with an application-specific root and capabilities list.
The executable might also be bound at creation time to installer-provided metadata. This could include, for example, a purchase receipt for access to paid content. If Firefox binds the executable, it will pass through the installData provided by the installing website; if a server binds the executable it is free to put whatever it wants in there.
==== Profile Management ====
User preferences for network, security, privacy, identity, saved passwords, form history, accessibility, application handling, and plugins should be identical across all WebRT-powered applications and their Firefox browser (if they have one). The HTTP cache is shared between WebRT-powered applications and Firefox, subject to the usual no-shared/no-store cache-control rules. Browsing history and bookmarks are not shared between WebRT applications and Firefox. If the user has installed Firefox and set up Firefox Sync, user preferences should be correctly synced across all devices; no support for Sync is expected if the user has not installed Firefox.
==== Profile Configuration ====
A WebRT preferences dialog is made available to the user through an OS-appropriate configuration flow; this dialog is functionally equivalent to the Firefox preferences panel. Additional product work is needed on each target platform to decide whether this appears as an "application" or is integrated into the platform-specific Settings / Preferences / Control Panel idiom.
==== Permissions and API Access Control ====
The WebRT binary enforces per-call permissions on API calls made by web content. It implements a set of sensible defaults for all applications and a set of higher-privilege defaults for applications installed from trusted sources. The list of trusted sources is maintained in the user profile. OS-appropriate interfaces for privilege escalation are provided, much the same as in normal-mode Firefox.
* Question: Are there any APIs that we would put in WebRT that we wouldn't put in normal-mode Firefox? Right now we don't have any, and that is a Good Thing. One possibility is "subwindows", for things like palettes, but perhaps that can fit into Firefox just fine with a bit of native widgetry?
==== Pre-download of Application Cache content ====
The WebRT executable should be able to initiate an Application Cache download, headlessly, in response to an IPC, and to message its status.
* Probably: Firefox should use this feature to provide a "downloading application" progress bar following the initiation of an install flow. When run in stub installer mode, the WebRT executable should provide a progress bar for resource download, which must complete before the first window is created. Maybe this happens during a splash screen or something - but predictable behavior is provided.
==== Domain Capture / Pinning by Applications ====
When the stub executable is bound, the domain of the application is bound into it. The WebRT runtime will "pin" that domain to the application. Any navigation event that occurs inside the application which stays within the pinned domain will be handled by the application, subject to the normal "target" rules to identify the target window. A navigation event that targets an external domain will be passed to the operating system for normal protocol resolution. A window.open event that targets an external domain will be converted into an OpenURL event, losing the open metadata.
* Question: Is Firefox expected to direct locations that would target an application over to the application? If so, how is the "target" attribute handled? How about calls to window.open? Can we make window.opener work for a popup in Firefox talking back to an external application?
==== Change Management for Application Manifests ====
When the stub executable is bound to an application manifest, it is given the URL of the manifest. WebRT is expected to apply ordinary Cache-Control rules to this manifest, and to poll it for changes when HTTP caching rules indicate that a freshness check is needed. Some coordination between WebRT and the stub may be necessary, such as (for example) when a system call must be made by the stub to respond to a request for a new capability in the manifest.
In limited cases, the user will be prompted to accept the new manifest before it becomes active. Currently, these cases are: an addition to the API capability list, a change of the application's icon, or a change of the application's name.
==== Support for native application-level widgets ====
There is some current platform work, and some HTML5 specification work, about creating application-level widgets from web applications. The WebRT project would need to accelerate some of that work; in particular, many operating systems expect to provide a toolbar or menu object.
==== Support for native application-level events ====
WebRT would be responsible for relaying OS-initiated events that target an application to web content, if appropriate. For example, an OS-initiated "Prompt for Quit" event might be turned into a series of "Close" events targeted at each open window, with content given a chance to prompt the user to save changes or cancel the quit.
* Questions: Which window gets unitary system-level events? Topmost? What if there's no window open (assuming the OS allows that)?
==== Support for "Show URL" and "Share URL" functions ====
We don't want to lose URLs, which are a great strength of the web - but an "application-style" user interface has no obvious place in which to display them.
A WebRT should be able to show, and share (using user-selected and platform-appropriate idioms) URLs.
=== TBD points ===
==== Support for Firefox install during WebRT startup? ====
More of strategy than a technology question: We could easily install Firefox when WebRT is downloaded the first time. Worth it? Distracting? Possibly offensive to developers or users?
==== Support for Multi-Window Applications? ====
More speculatively: A feature to allow more direct communication between windows of a WebRT application could be useful. This could be through a window.frames property or something like that.
==== Relationship of WebRT to Addons ====
* Feedback needed: There's no technical reason why addons and Jetpacks couldn't work inside a WebRT application, but the maintenance and configuration UX workload would be a bit greater. Thoughts?
=== Release and QA Implications ===
If WebRT is packaged as a separate library from Firefox, it would need its own build process; it is expected, however, that anything that would cause a Firefox spin would cause a WebRT spin. (And see below for thoughts about how the WebRT product could, in fact, just be the firefox binary).
=== Results of experimentation on Android ===
: Currently fennec opens webapps in special tabs and not in new chromeless windows (these tabs are specials in that we just re-focus them if you launch the same app twice). We had code to open in new windows but this does not provide a good user experience since from an Android point of view, it's just the same app (fennec). New windows does not show up in the app list on tablets for instance : the lack of a real window manager on android is a real issue here.
: Fabrice Desré
= How is this different from XULRunner today? = Technical Specification == Explicit targeting of web applications == The goal of WebRT is not to creative native applications using web technology -- it's to run web applications as full citizens on a native platform. WebRT is just a user agent, not a new platform. WebRT is anchored on a URL, and exposes all behavior to applications through the window and navigator objects - for a developer, it's just the web. In XULRunner , the root of the application is in XUL - sometimes a very small piece of XUL, but it's there. This isn't to require that WebRT doesn't have any XUL - that's an implementation detail - just that the developer's experience of using it is all web. == Focus on deployment through stub installer and existing Firefox installed base == Our goal is to support application install through existing binary distribution channels - that is stores run by other vendors - without necessarily asking users to change their primary browser. = Hm, couldn't Firefox do all this? = If Firefox is installed, it probably could - that part is fairly easy. We could have a stub executable which targeted the firefox binary and used it as a window server, or which spawned multiple firefox processes with some sort of shared-profile work. Making the experience good for users who don't have (and possibly don't want) Firefox is harder. We don't want to force a new web browser on people - our goal is to give web developers a way to easily deliver their web application to users. Research on users of mobile platforms has been very clear that users do not want to run apps inside their browser, and developers of interactive experiences (as opposed to hypertext content) have expressed great interest in providing a direct, unmediated experience to their users. It may be the case that the easiest way to deliver WebRT is to just make the stub installer download and install Firefox, and for the stub installer to invoke Firefox in a chromeless/anonymous mode. The goal of this specification is to make clear what that mode would look like, and to describe it in terms of its value to developers. This specification is trying to stay away from saying what the software packaging that makes WebRT happen looks like - it may very well be the existing firefox-bin executable, rather than a dynamically loaded library, for example. But to the end user and the developer, the experience the very different. == How do competing WebRTs happen? == That's happening already - all the other browser makers are hustling to add "application modes" to their browser products. The application developer, or application store, will use feature detection to see if the user's current browser can run their application (and potentially even run it in "application mode", for example [http://www.chromium.org/developers/design-documents/appmode-mac Chromium Mac App Mode]) - in that case, offering an executable download is totally unnecessary. = Engineering =
There are four basic implementation strategies:
{{note|The shortcut and APK strategies are not mutually exclusive, as it's possible to build a runtime that can do both. And the known source feature is a hard requirement that the runtime must support.}}
This feature/strategy matrix identifies some of the benefits and drawbacks of the various strategies:
|}
=== 2012 Plan =Schedule ==
=== Android === The Android runtime engineering goal for 2012 is to ship a production-quality runtime that integrates gives Android users of web apps into the a great user experience consistent with that of native Android apps experience. To do this, we'll start build on Soup by implementing the APK launcher strategy for devices that support it, while falling back to the existing shortcut strategy for those that don't. And then we'll prototype using Gecko as the rendering engine for the runtime.
* Milestone One: Mobile World Congress (MWC) - February 27
* Milestone Two: End Q1 - March 31
** implement APK launcher strategy with fallback to existing shortcut strategy
** prototype a using Fennec/Gecko componentas the runtime/rendering engine* Milestone [X]Three: Marketplace Launch - June [XX]
** ?
==Team = Open Questions = * Product Manager: ticachica* Engineering Manager: bwalker* Technical Lead: myk* Engineers:** digitarald (Android)** danw (Mac, desktop, platform)** tima (Windows, desktop) ==FAQ == === How is this different from XULRunner today? === ==== Explicit targeting of web applications ==== The goal of WebRT is not to creative native applications using web technology -- it's to run web applications as full citizens on a native platform. WebRT is just a user agent, not a new platform. WebRT is anchored on a URL, and exposes all behavior to applications through the window and navigator objects - for a developer, it's just the web. In XULRunner , the root of the application is in XUL - sometimes a very small piece of XUL, but it's there.
This isn't to require that WebRT doesn't have any XUL - that's an implementation detail - just that the developer's experience of using it is all web. ==== WebKit Versus Gecko Focus on deployment through stub installer and existing Firefox installed base ==== Our goal is to support application install through existing binary distribution channels - that is stores run by other vendors - without necessarily asking users to change their primary browser.
==== Store/Dashboard Activities =How do competing WebRTs happen? ===
That's happening already - all the other browser makers are hustling to add "application modes" to their browser products. The Developer Preview included separate Marketplace application developer, or application store, will use feature detection to see if the user's current browser can run their application (and Dashboard activitiespotentially even run it in "application mode", but integrating Dashboard functionality into the Marketplace activity may provide a better UXfor example [http://www.chromium.org/developers/design-documents/appmode-mac Chromium Mac App Mode]) - in that case, offering an executable download is totally unnecessary.
