The application directory should be updated to use stable APIs. (this is the thing hosted here: https://apps.mozillalabs.com/directory.html)

for now, both and a fixed .well-known URL

See what is broken, what can be automated, what can be pushed, figure out what the interface is, and where we can go.

introduce , possibly pagemod to handle services like smoothtransition, etc.

Here's an example:

navigator.apps.install({
  url: "theband.webapp",
  onsuccess: function() {
    alert('OMG');
  },
  onerror: function(wtf) {
    console.log(wtf);
  }

Doing this results in the app manifest being retrieved properly and the app being installed, but once installed, if the user goes to the gear icon in Firefox's browser chrome and selects "Manage Apps", then "View Manifest" for the installed app, the "origin" key of the manifest is set to undefined://.

To work around this, we changed the url key to be an absolute URL.

Whatever the implementation is (jschannel, direct API injection, etc...), the approach for an OWA to register for certain services should be something like:

navigator.apps.services.registerHandler('login', 'doLogin', function(credentials, return_cb) {
   // do something

   // return the result
   result_cb({...});
})

The HTML5 app dashboard should be updated for the new stable apis, and should have widget support.

Stable API and manifest docs, as well as overview and perhaps issue #19 (how to build a store) should be moved to MDN. Remaining documentation in-tree should all be reviewed and edited for the integration release.

To show some of the more advanced features of browser extensions and the android app we should put together a short screencast which demonstrates some of the most interesting features.

We may also want to include short preview of our upcoming "ux gallery", or we may want to break that into a separate 'cast...

What's now and what's next.

postMessage isn't working very nicely when the script is no longer truly chrome-privileged, so it's as good a time as any to rework the service discovery piece to use the more solid Jetpack libraries.

this will allow an app to receive a new URL that a user clicks on and have that app transition appropriately.

(It's not clear this is the behavior we want, but we're going to try it.)

A top level property of applications in local storage is 'app'. This actually holds the application manifest. Given that a second level key is also 'app', we should change this.

specifically, name and description could use a specified maximum size, validator and tests should be updated accordingly.

The firefox extension should be published on AMO in preparation for integration release, and linked from the updated dashboard, so that interested folks can install it and try it out with minimal fuss.

Needs a whole bunch of refactoring to make sure we are bootstrap friendly.

The manifest format is in the process of changing in the openwebapps plugin, the HTML5 shim and unit tests need updated as well.

currently default_locale is a required field. Given that the only other required field is name, it seems someone silly.

proposal is to make default_locale optional except when the locales map is present. This way a simple manifest stays simple, but once a developer goes to do l10n, the locales dependency on default_locale will help the validator help them understand how l10n is intended to work.

Line 33.

allow the gmail app to capture mailto:

link-rel in IFRAMEs is (a) dangerous and (b) causes race conditions when more than one.

Here's a report from a user:

• When I install the plugin, the black gearwheel appears to the right of
  the search box as I presume it should...but on my OpenSuSE 11.3 64bit
  machine, clicking on the gearwheel produces a very brief flash of a
  black panel just below the gearwheel - then nothing.

urlmatch by default allows user@pass in all urls it handles. proposal is to normalize this away, or to throw hard errors when it is present.

with its various services, on flickrconnector and in openwebapps.

Installing applications with the Firefox extension, I cannot see them on the dashboard (at https://myapps.mozillalabs.com/) -- running navigator.apps.mgmt.list() seems to return a permission error:

["permissionDenied", "to access open web apps management apis, you must be on the same domain as the application repository"]

Whenever you click on 'manage webapps' a new tab gets opened. Instead the tab has to be found which already has about:apps open. Have a look at the Add-ons Manager how it has been done.

When you open the notificiation panel by clicking the webapps button in the toolbar, and selecting an app or click on manage apps, the notification doesn't close. In nearly all the cases the user wants to directly switch to an application or to about:apps, and doesn't need that panel anymore right after. Currently it's in the way and annoying that you have to close it yourself.

Our injector runs too late to provide the navigator APIs to pages that load on session restore. We should fix this.

We need to run unit tests and do basic user testing across our supported browsers:

Tier 1: IE 9, Chrome 9, Firefox 4 (desktop and mobile), Safari 5x
Tier 2: IE 8, Safari Mobile, Android Mobile, Opera 10

By default, bookmark bar is not shown, but if user turns it on, should we forcefully hide it in app tabs? Probably, but needs discussion.

Given that we've migrated toward more abstract hooks for store authors, we should provide a walk through document to get potential store authors started.

when a user installs an application through the app directory, it's unclear what to do next.

To understand, install an application from here: https://apps.mozillalabs.com/appdir/

Perhaps some feedback immediately after installation pointing the user at the app dashboard? Something in the vein of what's done at http://appmanifest.org?

It'd be useful to demo some of the features and interactions of the openwebapps android app for the integration release. It should be in a demoable state (and perhaps an .apk should be available for installation for those on the bleeding edge).

The chrome extension needs to be packaged and hosted and available for folks to try out. Probably should be distributed through new application dashboard.

commit 556ee87

no new tab, no nothing.
gear icon pointing at the wrong sprite.
possibly restartless timing issue?

works fine on second run.

Right now the description is just "human readable", but there's no indication about how newlines or multiple spaces should be handled.

I recommend:

• The name is a single-line, and all whitespace is normalized to one space (i.e., newlines are equivalent to a space).
• The description can contain newlines and whitespace, and both are preserved when displayed. That means in the HTML case that newlines are replaced with <br> and multiple spaces use  . This allows, for example, simple indented lists.

High fidelity mockups showing browser integration, future design direction.

• Mozillaball - The simplest possible application which demonstrates
  how an application can trigger installation, and how
  the app can check if it's installed (self-hosted case).
• Task tracker - An application that demonstrates how purchase verification might work.
• Manifest Builder - (proposed) A simple tool that lets you author and verify a openwebapps manifest.
• Remove references to gmail app.

e.g. launch app, navigate app tab somewhere else, open up dashboard of apps, click the same app, brings app tab back but remains at new non-appy URL.

Test needs updated to reflect this.

I think it would be useful to have a document describing the terminology we are using. E.g.,:

• "app"
• "repository"
• "HTML repository" (my proposed term for the HTML5-based repository implementation)
• "browser-native repository" (UA-native?)
• "Dashboard"
• "Anonymous apps" (which kind of don't exist, and I think should be renamed anyway as I'm not clear how "anonymous" relates to the idea)

A clean design, and better presentation of what web apps mean for:

• ...users.
• ...developers.
• ...stores.

Depending on the browser the user is using, we should offer extensions directly from the application directory (https://apps.mozillalabs.com/appdir/)

15:51 < davida> I'm concerned that people will make their way to the appstore w/o knowing about the add-on, but the experience w/ the add-on is so much better
15:51 < davida> so if it's not already done, i'd suggest detecting browsers that have add-ons available for them and upselling them in the appstore

This is a browser based test since it is a shared module.