Canmove, confirm
2,056
edits
Changes
no edit summary
{{draft|}}
WebRT is a runtime for project to build web application runtimes that provide web applications that gives them with a native-like look and feel along with platform integration APIs on Android, Windows, Mac, and other platforms.
== Product Requirements Android ==
== Desktop ==
* Works with any trusted store through navigator install APIs; need UX March 13 - Firefox 13 Merge to add trusted stores.Aurora:* granting the superset of APIs at install time is a big speedbump* enable mozApps API on mozilla-central {{done|}}* current belief is that* land initial implementations of installer, since these aren't APKslauncher, no Android settings tweaks are neededand shell on mozilla-central {{miss|}}* cjonesApril 24 - Firefox 14 Merge to Aurora: silent update ** land initial implementations of runtime may not be possible; alsoinstaller, if we want launcher, and shell on mozilla-central {{ok|}}* June 5 - Firefox 15 Merge to share profile with WebRT it has to be in the same .apk (qAurora: not just the same signing key?)
==== Windows, Classic, Firefox =References ===
==== Windows, Classic, non-Firefox ==Meetings ==
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. When the user launches the executable, it checks for the WebRT libraries, doesn't find them, and initiates a download; when that download completes, the application launches with normal Windows behavior. * cjones: to support Windows uninstall behavior, we need a full install step, branding, etc. ==== Mac ==== ==== Linux ==== ==== Windows Metro ==== ==== iOS ==== === Features === {{note|The content of this section is under review.}} ==== Stub Executable ==== The stub executable is a platform-specific executable that starts an app by invoking Firefox in "webapp mode," using Firefox's -webapp command-line flag to specify the manifest of the app to start. The executable is bundled with Firefox, and Firefox makes a copy of it and binds the copy to the app manifest when a user installs an app. The executable updates itself if needed when it starts up by checking the Firefox version and replacing itself with a new version when the version of Firefox has changed. If Firefox can't be found, the executable notifies the user. In the future, the executable might be enhanced to prompt the user to locate Firefox via a file picker dialog or guide the user through a Firefox install/upgrade. ==== 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. Permissions that enhance the application experience should be defaulted to higher settings than the Firefox defaults; for example, Application Cache should be enabled by default and set to a high quota. Access to privacy-sensitive APIs should still be subject to more control and user oversight. A permissions UI for the application can be opened from inside the application using an OS-appropriate gesture. This UI should have the same functionality as the per-domain about:permissions pane. The application manifest may optionally include a capability to allow the application to register protocol handlers or content types. The runtime will take care of performing the registration automatically during installation. * 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 project gives status. ''This is a SWAG at better AppCache UX. More research is needed to be sure about this, and people are working on it.'' * 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. The application manifest may optionally include a "whitelist" of domains that the application is allowed to load without triggering the external-domain logic. If the application expects to load external top-level domains (e.g. for a federated login), it is expected to place the list of domains into its manifest. * 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. OS-level IPC events that target an application with content will need to be translated into web events. For example, dragging a document onto a WebRT-powered application should generate a "open document" event targeted at some window. * 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. ==== Native Integration ==== Apps running on WebRT look and feel like native apps via integration into the native APIs and affordances for installation, uninstallation, discovery, launch, and management. This integration will vary by platform and will not be complete, as some native functionality will be prohibitively difficult to integrate or would not provide the optimal user experience. ===== Cross-Platform ===== * graceful offline behavior: ?* full screen/chromeless: ?* instant on: ?* device/filesystem access: * elevated privileges by default: * protocol handler/file type associations: * native menus* restore window state: when an app is quit and restarted, the positions and sizes of windows are restored to the state they were in when the app was quit* native menus: apps can specify menus and menuitems to appear in the native Mac menubar* scrollbars: apps have control over the appearance of scrollbars (myk: don't they already?) ===== Android ===== * 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" ===== Windows ===== * Start menu entry: an entry in the Start menu* desktop icon: an icon on the desktop* Program Files entry: an entry in the Program Files folder weekly [[nonApps#Apps_Engineering_-goal]* registered uninstaller: an executable that uninstalls the app that can be invoked from the OS's list of installed apps* app icon in taskbar: an entry in the taskbar with a custom icon for a running app* pin app in taskbar: the ability to pin an app to the taskbar such that its entry in the taskbar is persistent ===== Mac ===== * /Applications: installer puts the stub executable in the system-wide /Applications folder* LaunchPad: when an app is installed, add it to LaunchPad, open LaunchPad, and show the user where it is* auto-add to dock: when an app is installed, automatically add it to the dock (parity with Apple App Store)* quit on close window: when all windows of an app are closed, the app quits (consistency w/web model, although uncommon for apps on Mac) === 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_WebRT. 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 useful2C_WebAPI. This could be through a window2C_Dashboard.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. : We also implemented stub apks that launched fennec in webapp mode. This doesn't give much to us, and doesn't work on some carriers (eg most of AT&T phones prevent install of 3rd party apps). : Overall Android is quite hostile for this kind of effort... much more than maemo was for instance. : One option could be: turn webRT into a android homescreen web application, and use it to do the window management part. This is similar to what is being done in b2g for the front-end. If we still want to support android native apps we can expose them to the window manager. This could run in a chromeless fennec, or as the fennec fork from b2g.The Mozilla Marketplace itself is just another webapp - and could come "preinstalled" with a bunch of others. : Interestingly, it looks like the "homescreen/launcher" section is very popular in the android appstore, so we could get some traction here. : Fabrice Desré == Technical Specification == === Android === There are four basic implementation strategies: * shortcut: an app that creates shortcuts for webapps on the user's homescreen* APK launcher: an app that installs lightweight APKs that launch a separate WebKit/Gecko runtime when launched* APK w/WebKit: an app that installs lightweight APKs that embed the native WebKit component* APK w/Gecko: an app that installs heavyweight APKs that embed Gecko {{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.}} The Developer Preview app, Soup, implements the shortcut strategy. This feature/strategy matrix identifies some of the benefits and drawbacks of the various strategies: {| |- align="left"! Feature! Priority! colspan="4" | Strategies|- | | | shortcut| APK launcher| APK w/WebKit| APK w/Gecko|- | icon on homescreen| ?| ✓| ✓| ✓| ✓|- | installed apps entry| ?| X| ✓| ✓| ✓|- | task switcher entry| ?| X| ✓| ✓| ✓|- | multitasking| ?| ✓ (w/fragments)| ✓| ✓| ✓|- | data sandboxing| ?| ✓ (emulated)| ✓ (emulated)| ✓| ✓|- | native uninstall| ?| X| ✓| ✓| ✓|- | native major updates| ?| ✓ (emulated)| ✓| ✓| ✓|- | native permissions| ?| X| ✓| ✓| ✓|- | known source| ?| ✓| X| X| X|- | graceful offline behavior| ?| ?| ?| ?| ?|- | full screen/chromeless| ?| ?| ?| ?| ?|- | instant on| ?| ?| ?| ?2C_Apps_in_the_Cloud| ?|} === Desktop === The -webapp command-line flag to Firefox starts a Firefox process in "webapp mode," which loads an app into a chromeless native window containing a single content iframe. Each app has its own browser profile, although the process obtains some information about the app from the user's default browser profile. [TODO: describe Windows/Mac specific behavior on installation, i.e. creation of a .app/.exe executable.] == Schedule == === Android === We build on the "Soup" Developer Preview by implementing the APK launcher strategy for devices that support it, falling back to the existing shortcut strategy for those that don't. Then we refine the experience of using apps through further integration with the native platform, culminating in an initial release of the Mozilla Marketplace app, using WebKit as the runtime, by the end of June. Finally, we prototype using Gecko as the runtime; and if the prototype proves viable, we develop and land a Gecko-based implementation into mozilla-central in preparation for shipping it with Fennec. * '''Milestone One: Mobile World Congress (MWC) - February 27'''** update Developer Preview to use new marketplace API** make minor tweaks to Developer Preview UX as requested by MWC demoers** ''[stretch]'' implement APK launcher strategy with fallback to existing shortcut strategy* '''Milestone Two: End Q1 - March 31'''** implement APK launcher strategy with fallback to existing shortcut strategy* '''Milestone Three: Marketplace Launch - June''' - [[Apps/WebRTJunePRD|PRDEngineering meetings]]** Mozilla Marketplace app available in Android Store* '''Milestone Four: End Q3 - September 30''' ** prototype using Fennec/Gecko as the runtime* '''Milestone Five: End Q4 - December 31'''** Fennec/Gecko is the runtime and is on track to ship with the Marketplace app === Desktop === We implement the -webapp flag to Firefox, a chromeless appshell, and stub executables on both Mac and Windows. Then we refine the experience of using apps through further integration with the native platform. * '''Milestone One: Mobile World Congress (MWC) - February 27'''** stop opening the dashboard when an app is installed via the Developer Preview** make minor tweaks to Developer Preview UX as requested by MWC demoers* '''Milestone Two: Merge to Aurora for Firefox 13 - March 13'''** mozApps API enabled for Firefox on mozilla-central** -webapp and appshell in mozilla-central** stub executable generation on app install in mozilla-central** native menus, restore window state in appshell* '''Milestone Three: Marketplace Launch - June'''** Firefox 13 is the runtime and ships with -webapp, the appshell, and mozApps == Team == * Product Manager: ticachica* Engineering Manager: bwalker* Engineers (w/focus area(s) in parentheses):** danw (Mac)** digitarald (Android)** myk (appshell)** tima (Windows) == 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. ==== 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.
