Marketplace/getFeature

Overview

The implementation of getFeature has been complicated by the intersection of a few factors:

1. we are not yet a real packaged app (we are still a packaged iframe)
2. Where's My Water and Firefox Hello have feature detection requirements, and they will ship on devices before the end of the year

Reference materials from Product and UXD

• PRD
• PRD Extension

Where's My Water

It needs to use:

• asm.js - the precompile option was added to the app manifest in 1.4, but the permission was not added until 2.0.
• 512MB RAM - at least this amount of memory is needed to run.
• 80MB available storage to install or/update. (This is not a requirement to show up for the user.)

Firefox Hello

Needs new permissions for:

• mobileid
• moz-attention
• moz-audio-channel-ringer
• moz-audio-channel-telephony
• moz-firefox-accounts

These are available after OS version 2.0; mobileid will be used as the key for the entire set (meaning: we're only going to detect that one and, if present, assume the rest).

The marketplace that is shipping with 2.0 doesn't have permission to use getFeature, so we need to update the package regardless of the "real" vs "iframed" packaged app.

Development needed

For getFeature itself:

1. add a buchet for 512MB RAM minimum
2. enable feature detection
3. update developer submission tools

For being able to notify the user of an available marketplace update:

1. how do we determine it?
2. while we aren't attempting to force install (or any other clickable action from the update notification) for this project, if there is a permission that needs to be requested for it, we should add that now so it's there when we need it later

Issues

getFeature

1. There is an existing issue with getFeature() in that it will test for the existence of the API, but this could be out of sync with the actual hardware.

Updating the Marketplace

1. We cannot update the marketplace app on 1.1 (962524)
2. In order to accommodate the largest group of devices that have Firefox Hello on it (and Where's My Water available to it), we want 2.0 users to update their shipped marketplace with our new one.
   1. Rather than specifically target 2.0, we want to just notify all users if there's an update.
      1. we cannot force install the update
      2. unknown if we can detect that there is an update available for the marketplace already, or if there is an API we need permission for

The packaged iframe

There are a variety of options for implementing getFeature in the packaged iframe:

1. Iframe package does detection via getFeature in advance and postMessage()s it to the app. Problem: The old iframe package does not post the message, but we need to block on it before making the search API calls. How do we differentiate between an up-to-date package that is just taking some time to post the message and an old package that is never going to send the message? How long do we wait? Possible perf impact.
2. Iframe package does detection via getFeature in advance and passes it via the querystring. Problem: getFeature is asynchronous, blocking on it might also have a perf impact.
3. Iframe package passes via the querystring that it has getFeature (?getfeature=true) and waits for messages. Then the iframe knows it can postMessage to ask for features. Problem: This is getting complicated.

QA time needed vs timeline

In addition to the technical issues surrounding the iframe, there is the timeline consideration. QAing getFeature is involved and will take time:

1. If it takes so much time to QA that we cannot get this done in time for Where's My Water and Firefox Hello, we must consider implementing less of getFeature and focusing on only the parts we need for those two apps. This is not ideal.
2. If it takes so much time to QA that we CAN get this done in time, but we could also be a real packaged app by then, there is less point to pursuing the packaged iframe.

Future product feature phases

(From Caitlin Galimidi)

1. extend force install on marketplace
2. do a fota update to marketplace with the system update 1.1 open c zte (arog / clee / bialer)