Closed Bug 873599 Opened 7 years ago Closed 7 years ago

Create a capability/feature detection API (or object)

Categories

(Core :: DOM: Device Interfaces, defect)

defect
Not set

Tracking

()

RESOLVED WONTFIX

People

(Reporter: dbuchner, Unassigned)

Details

Developers and various other groups, like the Marketplace, need the ability to reliably feature detect things like:

- Granular, method and version level detection of support for Web Runtime APIs (regardless of permission level)
- Capabilities of the user's device, such as: GPU presence, performance characteristics, memory available, etc
- OS version
- True device name/make/model
blocking-b2g: --- → koi?
Here's a great example of the lengths we're currently forcing developers to go in order to optimize their apps - while novel, no one should have to execute a *timing attack* to determine a device's core count: http://blog.wg.oftn.org/post/51125082905/core-estimator

Cores, GPU, memory, etc, let's make sure we use this API to equip folks with what they need.
The problems here are really tricky.

* Basically all devices have GPU these days. So GPU presence isn't enough, what you want is capability information about the GPU. How do we define these capabilities?
* Number cores in the hardware is different from number of cores available to a given page/app. The number of cores available to a given page/app depends what other things are running in the background.
* Same thing for memory. Amount of memory available to an app depends on how many other apps are running, and what they do.
* Define "Granular method and version level". At what granularity. What about bugs?
* How do we expose device name/make/model without heading down the giant hole that we're trying to dig ourselves out of when it comes to UA strings?
* How do we expose all this information without resorting to annoying security dialogs, greatly increased fingerprintability, or signing solutions that cause mozilla to become gatekeepers.


Generally speaking we need comprehensive proposals here. Along with descriptions of the use cases that it aiming to address.

I do understand that the use cases are there. But solving them is not easy.
This feature will aid us greatly, but the must have is bug 876984. Together they allow us to intelligently transact app upgrades, block listing, and prevent undue breakage.
I won't dig into huge detail here, but I would trend quite carefully here on what we expose here to avoid the various problems we've had with the user agent string. As I said on other associated bugs, this needs a larger discussion before we decide to move forward with this.
+1 to what jsmith said. If we turn HTML app compatibility into a UA-string-like heuristic detection mess, we will be weeping for years and years.

The problem with UA strings is that people thing detecting thing A implies capability B, when they should be detecting capability B directly. As far as possible, let's enable people to directly detect capabilities.

Gerv
(In reply to Gervase Markham [:gerv] from comment #5)
> +1 to what jsmith said. If we turn HTML app compatibility into a
> UA-string-like heuristic detection mess, we will be weeping for years and
> years.
> 
> The problem with UA strings is that people thing detecting thing A implies
> capability B, when they should be detecting capability B directly. As far as
> possible, let's enable people to directly detect capabilities.
> 
> Gerv

The FUD here has reached epic, nay apocalyptic, proportions. We need to - scratch that, we *must* (for the sake of my sanity) - jump on a call so I can explain how this system actual works vs how it is being portrayed.
Cross-posting followup response to the discussion we had in person from email.

So I met with Matt & Daniel to understand their requirements for the feature capability API & the change manifest API. I then met with Fabrice to compare the notes I collected to get a developer's perspective on the problem. Here's a short summary of what I've gathered from these discussions:

1. Dan & Matt are looking for an API that allows for a simplified way to do feature detection using a string to figure out what the phone currently supports. In other words, something that's easily allows a web developer to figure out what's supported or not without having to do a giant JavaScript file which tries to query each API to figure out what's supported or not.
** Example: 'RTCPeerConnection=false,MozWebActivity=true,WebGL=true,h264=true,...'
2. There's concern around handling the use cases around when an app makes an update that breaks an old Firefox OS version, where the Firefox OS version is missing key features the app needs to function correctly.
** Example: App version 1 - 3 works on FF OS 1.01 and 1.1. In version 4, the app decides that it will no longer support 1.01, as 1.01 does not support a key feature that version 4 needs (e.g. getUserMedia).
3. In order to solve the concern in [2], the marketplace folks are looking for a way to figure out if the app version won't work under certain versions of Firefox OS using feature detection and the ability to prevent updating to the app that won't work on that Firefox OS version.
3a. Marketplace's proposal is to use a simplified feature detection API to figure out the case when an app makes a breaking change.
3b. Then, if we know the app won't work on some old Firefox OS version, Marketplace wants to use an API on mozApps to change the manifest URL to prevent an update to an app not supported on that version.
4. To meet the needs in [3] while not breaking our security model, I asked Fabrice's for his perspective on the problem. There seems to be agreement that the concept of the problem needs to be handled where an app makes a breaking change that will stop a certain Firefox OS version from working with that app. However, there was distinct concern about exposing an API that allows modification of the manifest URL, as that would fundamentally alter what the app uses as it's target URL if the app was hosted, for example (there's potential security concerns here as well). An alternative proposal was then thought about using the required_features manifest property for installs and updates. Such things we could do with a required_features manifest property includes:
4a. Allowing the app to indicate what are the blocking features that must work on the device in order to use the app.
4b. If a user tries to install an app on a Firefox OS version that does not meet the required_features specified, then we could give a clear warning to the user that the app won't work correctly on their Firefox OS version, as they are missing required features in that Firefox OS version.
4c. If a user tries to update an app on a Firefox OS version that does not meet the required_features specified in the updated app, then we could give a clear warning that the app might not work upon updating the app, as the Firefox OS version is missing certain required features specified in the app manifest.

That's where we stand right now in this discussion. [4] needs an opinion from Jonas on what he thinks we should do architecturally to handle the "this app version will break an old Firefox OS version due to missing a key feature." [4] provides a proposal to the problem, but there's such questions that still be answered such as:

* What properties would be supported in this required_features manifest property?
* Would we warn or block the user from installing/updating an app that specifies a required feature that the current Firefox OS version doesn't support?
* Is the required_features manifest property the right approach here to solve this problem? Or should we consider different alternatives, including the feature detection API + change manifest API?
* etc.

Jonas - Let me know what you think.
Thanks for the summary Jason. Apologies if any of my comments are off base or my questions have already been answered as I was unable to attend the live discussion.

(In reply to Jason Smith [:jsmith] from comment #7)
> 1. Dan & Matt are looking for an API that allows for a simplified way to do
> feature detection using a string to figure out what the phone currently
> supports. In other words, something that's easily allows a web developer to
> figure out what's supported or not without having to do a giant JavaScript
> file which tries to query each API to figure out what's supported or not.
> ** Example:
> 'RTCPeerConnection=false,MozWebActivity=true,WebGL=true,h264=true,...'

At first glance it seems to me that this method doesn't improve the life of webdevs as the string will need to be parsed to determine if the capabilities they require are supported. Can you elaborate on how this is easier or how Marketplace would make use of this string?

> 2. There's concern around handling the use cases around when an app makes an
> update that breaks an old Firefox OS version, where the Firefox OS version
> is missing key features the app needs to function correctly.
> ** Example: App version 1 - 3 works on FF OS 1.01 and 1.1. In version 4, the
> app decides that it will no longer support 1.01, as 1.01 does not support a
> key feature that version 4 needs (e.g. getUserMedia).
> 3. In order to solve the concern in [2], the marketplace folks are looking
> for a way to figure out if the app version won't work under certain versions
> of Firefox OS using feature detection and the ability to prevent updating to
> the app that won't work on that Firefox OS version.
> 3a. Marketplace's proposal is to use a simplified feature detection API to
> figure out the case when an app makes a breaking change.
> 3b. Then, if we know the app won't work on some old Firefox OS version,
> Marketplace wants to use an API on mozApps to change the manifest URL to
> prevent an update to an app not supported on that version.

As I understand it, this solution won't help for hosted apps for which the user doesn't necessarily have a local copy. Am I correct in assuming that this protection is only for packaged apps?

As well, many apps will require a server side component. Preventing an app from updating because it doesn't support a feature may still leave it in a broken state if the developer changes the server side.

I'm somewhat concerned by the inconsistent behaviour that may result in app updates as a result of this type of change. Has UX been consulted on this?
FWIW, some discussion occurred on this topic at bug 838614
FWIW I really don't think anything is going to happen here in time for Gecko 26.
Daniel and I talked. See bug 900241 for new proposal.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
blocking-b2g: koi? → ---
You need to log in before you can comment on or make changes to this bug.