Closed Bug 873900 Opened 7 years ago Closed 7 years ago

Add feature profile string to the minifest URL

Categories

(Marketplace Graveyard :: Consumer Pages, defect, P1)

defect

Tracking

(Not tracked)

RESOLVED FIXED
2013-06-06

People

(Reporter: basta, Assigned: basta)

Details

Consider the following scenario:

User X sees AcmeApp 1.0 in the marketplace and installs it. AcmeApp 1.0 is compatible with User X's device.

AcmeApp releases v2.0 which has a more restrictive feature profile. 2.0 is no longer compatible with User X's device. (User X can no longer see AcmeApp in the Marketplace.)

Under the current implementation, user X would still receive the incompatible update and the app would become non-functional in some regard.

Proposal:

- Include the feature profile string as a query parameter for the minifest URL
- When the device polls the mini manifest, serve the most recent version of the app that is compatible with the feature profile that's included.


Open questions:

- Should this be done on the client side when we do install() or installPackage()?
- Should this be done on the server side when we serve the app object with the manifest/minifest URIs?


Setting this as P1 because a.) it needs to happen before we start filtering with the feature profiles and b.) it's easy to add.

The actual logic in the minifest endpoint doesn't need to be implemented immediately, but if we don't have the parameter, we won't be able to add this functionality down the road for any user that installs now.
I agree this sounds like a problem.

To me this does change the intention of the mini manifest, which I believe was intended to be a static file that simply points to the zipped package along with some meta data about the package that can be displayed in the install dialog. Now it changes to a place where we can dynamically determine which package to serve depending on the requesting client. To me that sounds like a big change.

If we go this route I think the device side might also need to follow for cases where servers (either self-hosted non-privileged packaged apps, or other marketplaces) don't do this for them?

> - Should this be done on the server side when we serve the app object with the manifest/minifest URIs?

I don't think so. We only have a single minifest URL for each app. Solving it at the minifest means we solve it for both initial installs and also upgrades.

What happens if there are no compatible versions at all?

Should device side have a flag to enable/disable compatibility checking? If so, we'd need that passed to us also to override what we do server side.

CC'ing some device side people to chime in.
(In reply to Rob Hudson [:robhudson] from comment #1)
> > - Should this be done on the server side when we serve the app object with the manifest/minifest URIs?
> 
> I don't think so. We only have a single minifest URL for each app. Solving
> it at the minifest means we solve it for both initial installs and also
> upgrades.

Cool, moving to consumer pages.

> What happens if there are no compatible versions at all?

What happens when an app is deleted?

> Should device side have a flag to enable/disable compatibility checking? If
> so, we'd need that passed to us also to override what we do server side.

On the Marketplace side, UX might not like this option because while it would be a setting, it would be permanent for each app as it's downloaded until you uninstalled the app. Changing the setting wouldn't change the setting for previously installed apps.
Component: General → Consumer Pages
If the app is deleted from the marketplace, the device will just not find a usable update, so the user keeps the last updated version.

For the more general "feature profile" thing, I don't even know how you define such a profile, but we don't have anything like that on the gecko side.
(In reply to Fabrice Desré [:fabrice] from comment #3)
> If the app is deleted from the marketplace, the device will just not find a
> usable update, so the user keeps the last updated version.
> 
> For the more general "feature profile" thing, I don't even know how you
> define such a profile, but we don't have anything like that on the gecko
> side.

This is a very important issue, and we need to have clear solution in place for launch (if humanly possible). As it stands, we are left with a situation where an update to FFOS or an update of an individual app from the developer's side, that results in a change to the environment's feature profile, will saddle users with apps that no longer work.

There are a couple solutions, let's get a meeting together to triage and fix this as soon as possible.
OS: Windows 7 → All
Hardware: x86_64 → All
No need to spend time in a meeting. If you have solutions, explain them here. And yes, it's way to late to add any feature in 1.0.1, if we even need a change. I don't understand why apps won't gracefully degrade.
(In reply to Fabrice Desré [:fabrice] from comment #5)
> No need to spend time in a meeting. If you have solutions, explain them
> here. And yes, it's way to late to add any feature in 1.0.1, if we even need
> a change. I don't understand why apps won't gracefully degrade.

Consider this: an app developer releases an app now that uses web activities to take a picture. In a year, they release an update that converts the app over to use getUserMedia. All of the users that are on b2g18 are going to get an app that's broken on their platform. Even if the developer does the right thing and marks the app as requiring the getUserMedia flag on the Marketplace (so users without getUserMedia can't install the app), users that already have the app are going to get screwed when they get the update.

That's what this bug prevents. Users without getUserMedia will never see the update because their feature profile will tell the server not to serve them the getUserMedia update.

The problem that Buchner brings up with this solution (and it's a completely valid point, though it doesn't need to be in 1.0.1) is that once the feature profile is in the mini manifest URL, we can't update it once the feature profile changes. Consider the following scenario:

- User installs app which uses WebActivities for photos (user and app have feature profile "1.0")
- App switches to getUserMedia. App now has feature profile "2.0" and user with "1.0" profile doesn't get the update.
- User updates to b2g23 and his feature profile is now "2.0" because it supports getUserMedia
- User still doesn't get the updated app because the mini manifest URL hasn't change and still says "1.0"


Perhaps we can introduce an API to allow an app which install other apps to change the manifest (or minifest) URLs of the apps that it's installed. This would cover the shortcomings of this solution. Additionally, it would enable the Marketplace to do blocklisting on hosted apps, which we've had a lot of frustration with our inability to do so far.

All of that is outside the scope of this bug, but is definitely something that I think we need to meet about. I'll file a separate bug once I land this change.
(In reply to Matt Basta [:basta] from comment #6)
> The problem that Buchner brings up with this solution (and it's a completely
> valid point, though it doesn't need to be in 1.0.1) is that once the feature
> profile is in the mini manifest URL, we can't update it once the feature
> profile changes. Consider the following scenario:

If the device feature profile is part of the query string, the install wouldn't include it as part of the manifest url (and update URL), would it? Otherwise I'm confused by this.

If the query string isn't included we could assume compatible by default -- what we do now.
(In reply to Matt Basta [:basta] from comment #6)
> (In reply to Fabrice Desré [:fabrice] from comment #5)
> > No need to spend time in a meeting. If you have solutions, explain them
> > here. And yes, it's way to late to add any feature in 1.0.1, if we even need
> > a change. I don't understand why apps won't gracefully degrade.
> 
> Consider this: an app developer releases an app now that uses web activities
> to take a picture. In a year, they release an update that converts the app
> over to use getUserMedia. All of the users that are on b2g18 are going to
> get an app that's broken on their platform. Even if the developer does the
> right thing and marks the app as requiring the getUserMedia flag on the
> Marketplace (so users without getUserMedia can't install the app), users
> that already have the app are going to get screwed when they get the update.

But the developer did not the right thing. He should detect whether getUM is available or not and use either getUM or an activity.

How do you define your feature profiles? How will you cover possible permutations of available functionalities? I'm really surprised that we're going this way.

> Perhaps we can introduce an API to allow an app which install other apps to
> change the manifest (or minifest) URLs of the apps that it's installed. This
> would cover the shortcomings of this solution. Additionally, it would enable
> the Marketplace to do blocklisting on hosted apps, which we've had a lot of
> frustration with our inability to do so far.

But that means that the user has to go to the marketplace for this new API to be triggered. That won't work when just doing background updates.
About blocklisting, we'll have malware protection for b2g (see bug 863669).
(In reply to Fabrice Desré [:fabrice] from comment #8)
> (In reply to Matt Basta [:basta] from comment #6)
> > (In reply to Fabrice Desré [:fabrice] from comment #5)
> > > No need to spend time in a meeting. If you have solutions, explain them
> > > here. And yes, it's way to late to add any feature in 1.0.1, if we even need
> > > a change. I don't understand why apps won't gracefully degrade.
> > 
> > Consider this: an app developer releases an app now that uses web activities
> > to take a picture. In a year, they release an update that converts the app
> > over to use getUserMedia. All of the users that are on b2g18 are going to
> > get an app that's broken on their platform. Even if the developer does the
> > right thing and marks the app as requiring the getUserMedia flag on the
> > Marketplace (so users without getUserMedia can't install the app), users
> > that already have the app are going to get screwed when they get the update.
> 
> But the developer did not the right thing. He should detect whether getUM is
> available or not and use either getUM or an activity.
> 
> How do you define your feature profiles? How will you cover possible
> permutations of available functionalities? I'm really surprised that we're
> going this way.
> 
> > Perhaps we can introduce an API to allow an app which install other apps to
> > change the manifest (or minifest) URLs of the apps that it's installed. This
> > would cover the shortcomings of this solution. Additionally, it would enable
> > the Marketplace to do blocklisting on hosted apps, which we've had a lot of
> > frustration with our inability to do so far.
> 
> But that means that the user has to go to the marketplace for this new API
> to be triggered. That won't work when just doing background updates.
> About blocklisting, we'll have malware protection for b2g (see bug 863669).

OK, now the feature detection system we're doing is being misunderstood. I really would like to talk face to face about this. We have a great system in the Marketplace and this is an issue - with the problem being as described, this I assure you. Debugging this here just seems to be adding to the confusion.
Can you follow-up on the webapps mailing list please?
I don't think the solution is generally as simple as "don't push an update which is incompatible with the user's device".

Many times updates contain security fixes, and so not pushing the update puts the user at risk. So we'd want to at least ask developers that are pushing an update which adds additional requirements what to do for users that use devices which doesn't fulfill those requirements.

The idea was definitely that the mini-manifest URL would return a static file. Otherwise we get into trouble once we implement application sync where applications are synced to other devices which has other features. That said, that isn't implemented yet, so not something we need to worry about yet. It also doesn't work well in situations where an application is synced to a device which is lacking required capabilities.
(In reply to Jonas Sicking (:sicking) from comment #11)
> The idea was definitely that the mini-manifest URL would return a static
> file. Otherwise we get into trouble once we implement application sync where
> applications are synced to other devices which has other features. That
> said, that isn't implemented yet, so not something we need to worry about
> yet. It also doesn't work well in situations where an application is synced
> to a device which is lacking required capabilities.

How do you propose solving the issue of users getting app updates that don't work on their devices? In a perfect world, developers will put guards on their features to prevent users from hitting rough edges caused by compatibility problems. In reality, though, things as trivial as the <section> tag caused IE8 to choke on HTML, so that's not going to be realistic. Developers aren't going to check for getUserMedia or H.264 support someday, and users are going to get crappy updates.
(In reply to Fabrice Desré [:fabrice] from comment #5)
> it's way to late to add any feature in 1.0.1

+1.  We'll nom it for 1.1 (leo).
blocking-b2g: --- → leo?
This is a great discussion, and there is merit to both encouraging app devs to be proactive about feature detection as well as the marketplace protecting the user from updates that will break their app due to unsupported features and create a bad UX.

Given the case that Basta mentions where practically speaking app devs will in some circumstances break compatibility for portions of their user base inadvertently as they iterate on future versions, is there any way to close that loop and notify the developer via their dashboard into the marketplace? 

It would be important to know for example that I pushed an updated to my app that 10% of my existing users will never get, especially for the reasons that Jonas mentioned re security updates. This would give me a chance to push an update that does appropriate feature checking and thus restore an update path for those 10% that just got axed.
(In reply to tchoma from comment #14)
> Given the case that Basta mentions where practically speaking app devs will
> in some circumstances break compatibility for portions of their user base
> inadvertently as they iterate on future versions, is there any way to close
> that loop and notify the developer via their dashboard into the marketplace? 

Our validator is good but not great, and we couldn't say (programmatically) with certainty that an update would work everywhere. It's also not practical for our reviewers to have very old devices forever (would we still have our reviewers testing on Unagis in five years?). So the answer is "only sometimes".

> It would be important to know for example that I pushed an updated to my app
> that 10% of my existing users will never get, especially for the reasons
> that Jonas mentioned re security updates. This would give me a chance to
> push an update that does appropriate feature checking and thus restore an
> update path for those 10% that just got axed.

We can only do this if the developer does the right thing and adjusts their feature profile. If they say, "Yeah, we use API XYZ now," we can give them a warning and say "You sure? 15% of your users aren't going to be able to use this update."

That functionality, however, doesn't block the users from getting the update. If the dev says, "Yeah, I don't care," those 15% are going to get an update that breaks the app. OTOH, with the feature profile in the minifest URL, we can actually prevent those users from upgrading.

I started a discussion on dev-webapps to see if we can get an API to mitigate the issue raised by dbuc. If we can't update the manifest URLs once they're in there, I'm not sure implementing the feature in this bug is a very good idea because it means that users will be locked into old versions of apps "forever" ("forever" as in zip disks). If you have opinions, I encourage you to express them on the mailing list.
(In reply to Matt Basta [:basta] from comment #12)
> How do you propose solving the issue of users getting app updates that don't
> work on their devices?

I don't really have a good solution unfortunately.

One solution would be to enable the client side code to know which feature strings it supports and then put some sort of warning to the user if it detects an update (or even an install) of an app which requires features that it doesn't support.

But that's not something that we have yet. Nor do we have the UI to react to it even if we did detect an attempt to install something that's not supported.

But this might be the best long term solution.

I think for now sticking feature strings in the mini-manifest URL is an ok workaround. The server can always start ignoring those parts of the URL if we move to another solution later?
(In reply to Matt Basta [:basta] from comment #15)
> OTOH, with the feature profile in the minifest
> URL, we can actually prevent those users from upgrading.

FWIW, this is not a panacea either. This leaves the device, or more likely the user, with the hard choice of "update to a later version where something probably is broken, but we have no idea if it's anything important" or "stick with the old version which likely has security problems, or which could even be completely broken because it's interacting with a server which requires the new version".
Basta: Good to know re the validation process,  I think that the case where you mention where a developer adjusts their feature profile, but doesn't realize the implications that this has for their user base, a warning in this situation as you mention i.e. x% of your users will not receive this update because the marketplace will block it for compatibility reasons, would be very valuable and motivate them to rethink and feature detect. Especially as a given developer may not have access to those older phones.

The other motivating factor if the marketplace doesn't filter updates on feature profiles that would lead to developers correcting incompatibility issues is the 1 star reviews that will accumulate for that version of the app in the marketplace from those users. 

As a result of this, filtering out updates by feature profile would likely become an ask from app developers in the long run anyways, as they might not have the resources to support a long tail of older feature profiles and want to sunset support for older versions as the number of users on those devices/profiles taper off.

And this speaks to Jonas point as well, perhaps it needs to go further than the device not getting future updates for an app that is no longer supported, but that the app is turned off, or the app expires over some time period in which the user is warned.
(In reply to Travis Choma from comment #18)
> And this speaks to Jonas point as well, perhaps it needs to go further than
> the device not getting future updates for an app that is no longer
> supported, but that the app is turned off, or the app expires over some time
> period in which the user is warned.

My concern here is that if a user paid for the app, we should never make it unavailable to them. Same with a free app. If the app works perfectly fine on its own, we have no right to turn the app off on the user. Imagine if you were a user that paid $5.00 for an app and you get a lot of use out of it, and six months later it gets disabled because your carrier hasn't updated your version of B2G. If it happened to me, I'd be pretty outraged.

Even if we warned the user that they're out of date, it's more than likely that the user simply can't do anything about it. So showing them a warning, as I mentioned on dev-webapps, is almost a taunt that they can't use the app anymore.
(In reply to Matt Basta [:basta] from comment #19)
> (In reply to Travis Choma from comment #18)
> > And this speaks to Jonas point as well, perhaps it needs to go further than
> > the device not getting future updates for an app that is no longer
> > supported, but that the app is turned off, or the app expires over some time
> > period in which the user is warned.
> 
> My concern here is that if a user paid for the app, we should never make it
> unavailable to them. Same with a free app. If the app works perfectly fine
> on its own, we have no right to turn the app off on the user. Imagine if you
> were a user that paid $5.00 for an app and you get a lot of use out of it,
> and six months later it gets disabled because your carrier hasn't updated
> your version of B2G. If it happened to me, I'd be pretty outraged.
> 
> Even if we warned the user that they're out of date, it's more than likely
> that the user simply can't do anything about it. So showing them a warning,
> as I mentioned on dev-webapps, is almost a taunt that they can't use the app
> anymore.

Matt is correct - the boogeyman of per-app security updates not being allowed is a canard (though comically, you could argue that blowing up an operable app, thereby preventing use all together, is the ultimate state of security!...I digress).

We can't blast apps people have paid for because we employ a system too dumb to know the difference between variant levels of compatibility. Instead, let's talk solutions - I think we have a few options.
Matt/Daniel I think those are fair points. For paid users, the truth of the matter is, it's also not great UX to have paid for the app and be excluded from newer versions and features as well, but fair enough, if the developer is willing to continue to make sure the older version continues to work in terms of client/server interaction then it's better then nothing from the user's point of view.

I know this bug has a very specific focus, and I'm sure there are a few good ways forward. I'll leave the mechanics of it and manifest url modification to the discussion that's started the mailing list. I just want to list out some considerations that we may want to keep in mind as we find a way forward:

1. Will developers be aware that they have active installs/users that have fallen off the upgrade path via their marketplace dashboard? If they have to roll their own detection how do they tease apart people who are blocked from upgrading vs people who haven't bothered to upgrade. And will it be clear to the developer why this set of users are not getting upgrades if they start getting support queries for it?

2. If users are not warned, beyond  the marketplace silently shielding them from the update, do they see the update and screenshots for that update if they visit the app's page in the marketplace? If they don't, do they see the user reviews for that update, or is that app's page in the marketplace frozen as of the version they have?

3. Do we provide any support for developers who need to phase out support for older phones / feature profiles, or is it up to roll there own way of notifying users? If someone is not getting upgrades and the developer make a change to their server api and breaks the app, do they just eat the bad reviews from those users? Or in order to avoid that do they need to support every profile they ever shipped on indefinitely? Curious whether this is something people feel should be a platform concern or left to the app developer.
(In reply to Travis Choma from comment #21)
> 1. Will developers be aware that they have active installs/users that have
> fallen off the upgrade path via their marketplace dashboard?

It's not a feature slated for 1.0 of feature detection, but to the best of my knowledge it's set to happen before the end of the year, if not by Q4.

> 2. If users are not warned, beyond  the marketplace silently shielding them
> from the update, do they see the update and screenshots for that update if
> they visit the app's page in the marketplace? If they don't, do they see the
> user reviews for that update, or is that app's page in the marketplace
> frozen as of the version they have?

The user will not be able to see the app in the Marketplace if they search for it. They can only see it by going to the My Apps page or searching for it on Google or something like that.

If they do visit the app's page, they'll see a nice warning message telling them that the app isn't compatible with their device, and if they've already installed it, it should say that the app is not going to update. There are no plans to proactively notify users, though.

> 3. Do we provide any support for developers who need to phase out support
> for older phones / feature profiles, or is it up to roll there own way of
> notifying users?

There are no plans to provide a means for developers to contact users. We can write docs, though, explaining how to release a version that tells the user, "Hey, this app is no longer compatible with your device so you're going to be stuck on this version until you update."

> If someone is not getting upgrades and the developer make a
> change to their server api and breaks the app, do they just eat the bad
> reviews from those users?

Bear in mind that if the user *did* get the incompatible update, the app would be completely broken. The feature profile represents a hard-stop, this-app-no-longer-functions flag for the device.

> Or in order to avoid that do they need to support
> every profile they ever shipped on indefinitely? Curious whether this is
> something people feel should be a platform concern or left to the app
> developer.

I think that's up to the developer. The feature this bug covers meets parity with how Android works. If you have an Android app that is going to drop support for a platform, the platform you're dropping doesn't get updates and the app will eventually stop working. It's up to the developer to draw the line and say, "Sorry, but you're on 1.0.1 and it's 2015."

Along the same lines, web developers need to decide when to drop IE6/7/8 support in the same way. At some point, you're going to have to stop holding those users' hands and have them get an update or buy a new phone.

The nice thing about feature profiles though, is that it's not per-version. A simple calculator app might never get obsoleted (hooray for the web!). This profile means that apps will only get blocked from updates if the developer explicitly adds new features that aren't supported on older versions of the platform.
Another solution is, somewhere off the main app details page, we should publish the system requirements set by the developer.  At least a user may know what is needed in their device and upgrade it, if possible.  Or with push messaging, we can notify a user that an update is available but requires an OS upgrade, or that their device doesn't support it.

But ultimately it is the developer's choice whether they continue support for un-upgradable users.  

Perhaps we can also publish on dev hub, numbers about how many users have each feature, or trends on features, so developers can make intelligent decisions about installed bases and new phones.  

I see the proposed changes as positive though not perfect.
Component: Consumer Pages → DOM: Apps
Product: Marketplace → Core
Version: 1.0 → Trunk
Priority: P1 → --
Component: DOM: Apps → Consumer Pages
Priority: -- → P1
Product: Core → Marketplace
Target Milestone: --- → 2013-06-06
Version: Trunk → 1.5
This is still a Marketplace bug.
(In reply to Matt Basta [:basta] from comment #24)
> This is still a Marketplace bug.

Well, someone nomed it to block. Which makes it client-side when it's nomed.
blocking-b2g: leo? → ---
+Gerv
+Lawrence

What's proposed here sounds like a web compatibility nightmare. We should not, in any form, propose the use of strings to figure out what version to update to for apps. We should be promoting app developers to design backwards compatible apps, such that updating should allow usage on the oldest version of Firefox OS up the latest. If not, we're going to gun ourselves into the ground with the many problems we've seen with user agent sniffing.

The proposal above with getUserMedia vs. web activities for camera usage also wouldn't make sense to use a feature string for anyways. That's best done by feature detection while using the app at runtime to allow the app to be designed to backwards compatible.
It doesn't matter what developers could or should be doing. They can and WILL break backwards compatibility. That's not something that's not argued. On the marketplace side, if we know with absolute certainty that an update will cause an app to become nonfunctional on the users device, we should NEVER deliver that update. Especially if the user paid for the app.

I'll deal with this bug today. It won't change any functionality, but it will allow us to in the future. I'll create other bugs in conjunction with Buchner to get the rest of the implementation mulled over.
Hmm. Perhaps a better UX than not syncing apps to devices which don't support them (and so having the user wonder why the app isn't there), is syncing the app but having the device put up a message saying "This app was synced from one of your other devices but sadly this device doesn't support it" when the user tries to run the app. Perhaps also we could grey out its icon in the launcher as a visual indicator.

IOW, can we do client-side runtime compatibility checking, as well as the server-side "you can't download this app because this device doesn't support it" checking?

Gerv
If we disable the app, we've still broken the app and we've not made the experience better. 

Once the broken update hits the device, it's game over. The user has a broken, nonfunctional app that they may have paid for. No amount of messaging is going to make their experience better at that point.
(In reply to Matt Basta [:basta] from comment #27)
> It doesn't matter what developers could or should be doing. They can and
> WILL break backwards compatibility. That's not something that's not argued.
> On the marketplace side, if we know with absolute certainty that an update
> will cause an app to become nonfunctional on the users device, we should
> NEVER deliver that update. Especially if the user paid for the app.
> 
> I'll deal with this bug today. It won't change any functionality, but it
> will allow us to in the future. I'll create other bugs in conjunction with
> Buchner to get the rest of the implementation mulled over.

Keep in mind that as the client-side bug cites (bug 876894), there isn't consensus to implement this functionality. I think there's a general consensus right now that the client-side team is not in agreement with the Marketplace team here on the approach. If you go forward with any implementation here, it might get removed later if such a conclusion goes against it.

I'd suggest going with Dan suggested - get a couple of people into a meeting room and discuss this. This needs to include client-side and marketplace guys to conclude:

- If this is something we should do (agreement between client & marketplace)
- If we should do it, what client-side changes should we make?
- If we should do it, what marketplace changes should we make?

Caitlin - Can you rally people together to work this out?
Flags: needinfo?(cgalimidi)
+1 to Jason's comment 26. We should encourage app authors to gracefully degrade their app experience just as we encourage Web authors to gracefully degrade the experience of their sites on the open Web. As well, we have been actively encouraging site authors to get away from using device profiles. We should not provide one in our platform. (Each platform has its requirements. This is something that app authors building for the Web should learn just as they needed to learn how to build Android and iOS apps.) This doesn't mean that we shouldn't help them but we don't necessarily need to include this help in the platform.

For the use case of 'hiding' apps in the Marketplace from devices that are incompatible, can the Marketplace create its own device profile through feature detection and have App authors mark required apis in their app definition? (This may be in the manifest, through the app registration process, some other means.)

In terms of updating, I really don't think that Mozilla should be in the position of being the update police. As a Marketplace, we are a clearinghouse for apps. It seems to me that the contractual relationship when funds are exchanged is between the app author and the consumer. Mozilla may or may not play the role of broker. If an app author breaks a lot of consumers they should understandably be upset with the app developer and demand a fix. AFAIK, apps can update and break the user experience outside of the Marketplace as well and we will have no control over that.

Have I missed something in the comments above or am I missing background for this conversation?
(In reply to Lawrence Mandel [:lmandel] from comment #31)
> +1 to Jason's comment 26. We should encourage app authors to gracefully
> degrade their app experience just as we encourage Web authors to gracefully
> degrade the experience of their sites on the open Web. As well, we have been
> actively encouraging site authors to get away from using device profiles. We
> should not provide one in our platform. (Each platform has its requirements.
> This is something that app authors building for the Web should learn just as
> they needed to learn how to build Android and iOS apps.) This doesn't mean
> that we shouldn't help them but we don't necessarily need to include this
> help in the platform.
> 
> For the use case of 'hiding' apps in the Marketplace from devices that are
> incompatible, can the Marketplace create its own device profile through
> feature detection and have App authors mark required apis in their app
> definition? (This may be in the manifest, through the app registration
> process, some other means.)
> 
> In terms of updating, I really don't think that Mozilla should be in the
> position of being the update police. As a Marketplace, we are a
> clearinghouse for apps. It seems to me that the contractual relationship
> when funds are exchanged is between the app author and the consumer. Mozilla
> may or may not play the role of broker. If an app author breaks a lot of
> consumers they should understandably be upset with the app developer and
> demand a fix. AFAIK, apps can update and break the user experience outside
> of the Marketplace as well and we will have no control over that.
> 
> Have I missed something in the comments above or am I missing background for
> this conversation?

Beep beep back the truck up. I'm seeing a lot of this:

"We should encourage app authors to gracefully degrade their app experience just as we encourage Web authors to gracefully degrade the experience of their sites on the open Web."

and this:

"We should be promoting app developers to design backwards compatible apps, such that updating should allow usage on the oldest version of Firefox OS up the latest."

Which tells me immediately that there is a HUGE misunderstanding going on. Folks, this is not a question of coding an app for graceful degradation on various devices - no one here is questioning that this is the first line of defense.

The system proposed allows us to do two things:

1) Show users only apps that are available for install given their device/environment

2) Ensure that apps that break compatibility with the user's device (things can break for many reasons, not just because an app developer is being lazy or fails to code their app with and eye toward graceful degradation, etc) we don't take a bazooka and blow their app to smithereens under entirely avoidable circumstances.

Use Cases:

I'm an developer who creates a twitter-like app, in v1 the camera is a small feature that is if() checked and only provided as an additional perk to those who want to include photos in their posts. v2 comes along, and the dev realizes photos are the feature people are using 85% of the time, so they pivot to being more of an instagram-like app - now the camera becomes a mandatory feature in the app. Mind you, the old version works, but under the current system, we'd send v2 down to the user and it would make a large BOOMing sound when it arrived on the user's device.

Moral of the story: if for whatever reason you break my apps and don't need to, I'm pissed, I'm kicking some dirt, I'm blaming your update mechanism and your OS. Period.

^ that's the harsh truth from a user's perspective - don't kill the messenger here, let's focus on solutions.
I think at this point we need to go to a meeting to talk about this. I've got responses to the above comments, but I think we're just going to spin in this argument if we keep going.
(In reply to Daniel Buchner [:dbuc] from comment #32)
> Which tells me immediately that there is a HUGE misunderstanding going on.
> Folks, this is not a question of coding an app for graceful degradation on
> various devices - no one here is questioning that this is the first line of
> defense.

Thanks for clarifying the scenario.
 
> The system proposed allows us to do two things:
> 
> 1) Show users only apps that are available for install given their
> device/environment

As I said above, it seems to me that we can support this requirement via the Marketplace performing feature detection and the app listing there hard feature requirements.

> 2) Ensure that apps that break compatibility with the user's device (things
> can break for many reasons, not just because an app developer is being lazy
> or fails to code their app with and eye toward graceful degradation, etc) we
> don't take a bazooka and blow their app to smithereens under entirely
> avoidable circumstances.

Am I correct in assuming that this is only an issue for packaged apps? How can we prevent update for an app that the dev hosts on their on server?
 
> Use Cases:
> 
> I'm an developer who creates a twitter-like app, in v1 the camera is a small
> feature that is if() checked and only provided as an additional perk to
> those who want to include photos in their posts. v2 comes along, and the dev
> realizes photos are the feature people are using 85% of the time, so they
> pivot to being more of an instagram-like app - now the camera becomes a
> mandatory feature in the app. Mind you, the old version works, but under the
> current system, we'd send v2 down to the user and it would make a large
> BOOMing sound when it arrived on the user's device.
> 
> Moral of the story: if for whatever reason you break my apps and don't need
> to, I'm pissed, I'm kicking some dirt, I'm blaming your update mechanism and
> your OS. Period.
> 
> ^ that's the harsh truth from a user's perspective - don't kill the
> messenger here, let's focus on solutions.

In this case, instead of having the server know whether a client should be pushed an update, how about having the client make the determination about whether it can accept an update? This can be accomplished by sending additional metadata about the app's requirements and prevents the need for the device to communicate its feature set via a device profile string, the UA, etc.
(In reply to Lawrence Mandel [:lmandel] from comment #34)
> As I said above, it seems to me that we can support this requirement via the
> Marketplace performing feature detection and the app listing there hard
> feature requirements.

We are already planning to do this.

> Am I correct in assuming that this is only an issue for packaged apps? How
> can we prevent update for an app that the dev hosts on their on server?

Yes, this use case only targets packaged apps. However, we'll be passing the feature profile to *all* manifest URLs to allow the developer to implement their own solution if they so choose.

> In this case, instead of having the server know whether a client should be
> pushed an update, how about having the client make the determination about
> whether it can accept an update?

Two problems here:

1. This isn't a feature currently so all of our current users and users for the foreseeable future won't get the benefit of this.
2. The client would need to know what features it supports and which ones it doesn't. We shouldn't need a platform update for the platform to know that it does or does not support a particular feature.

The Marketplace can do this today, and that's why we're shipping this feature.

Note that this has other uses:

- Getting stats on what devices have your app installed
- Giving developers information on the consequences of modifying their app's minimum requirements
- Loads more developer-focused stuff.
https://github.com/mozilla/fireplace/commit/16a1822ec444a05f63f0553e3086e0baf56be4f6

We can have meetings and talk about this offline. For now, this adds the functionality originally described by comment #0.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Talked to Caitlin over email - she's looking into getting people together for a session to work this out.
Flags: needinfo?(cgalimidi)
Assignee: nobody → mattbasta
y'all - this was h*ll week
so sorry to let this slip
i'll invite all on this bug - you can decline if not needed...
Something doesn't compute here:

1) The platform only allow one app per URL/path
2) If an app URL/path contains a slightly different parameter in a URL for an app it already has installed, the platform considers it a second app and tries installing a duplicate

^ The platform is apparently not playing by its own rules - and I can't imagine a scenario where the resulting behavior is desired. Why would the platform try to install an app again - as a second, duplicate copy - instead of simply updating the app that matches the path of the corresponding, pre-installed app?
We're being quite consistent. The path part of a URL is no more or less important than any other part. You need to look at the full URL. So:

1) The platform only allow one app per URL
2) If an app URL is slightly different from the URL for an app it already has installed, the platform considers it a second app and tries installing a duplicate.

So yes, the URL is what identifies an app. If it's a different URL, it's a different app. We can't use the path only as an identifier since that wouldn't allow a website to use URLs like:

https://example.com/manifestserver.cgi?app=GhostWarriorSlayer3000

Actually, that brings up a good point, putting meta-information that can change over time into the manifest URL is a very bad idea. That means that you have to change the identity of an app whenever the metainformation changes. Lots of APIs use the manifestURL to identify an app, for example apps.checkInstalled requires knowing the manifestURL. So if you change that anytime the feature profile of the app changes, that will make the developer's and the store's life a lot harder.
None of us were excited about the idea at the time but it was considered the best stopgap (see your own comment 16).  I'll happily participate in a conversation about better alternatives but I don't feel like I'm in a good position to suggest them as I'm not super familiar with what we have on the platform.  

As a starting point, here's my pie-in-the-sky idea: the client sends compatibility info in the request headers when it looks for upgrades and the server could adjust its reply on the fly.

(this is likely a better conversation to be had on a mailing list)
> the client sends compatibility info in the request headers when it looks for upgrades and the server could adjust its reply on the fly.

If there was a way that the Marketplace could provide some sort of persistent information that got sent on every update ping to the minifest, that would work just fine. There was a suggestion that this could be accomplished with cookies, but that turned out not to be the case.
If one isn't already filed, please file a bug on the inability to use cookies. This is the web, cookies should just work.
You need to log in before you can comment on or make changes to this bug.