983880 - [tracking] Use feature-detection API

Status: RESOLVED WONTFIX

(Marketplace Graveyard :: General, defect, P3)

Description

[Wil Clouser [:clouserw]]

The feature detection API is going to be privileged for now which means we'll need to request the permission in the marketplace we ship with 1.3.  We should do this as soon as we can since their code is freezing.

We can do this before bug 983502 closes if we know what the permission is called and if requesting a non-existent permission is simply ignored by the client.

Requesting 1.3T? because the Marketplace is a packaged app and needs to ship with this on the phone if we're going to support low memory app filtering.

Comment 1

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Note that only the pages in the app-package itself will have access to the API. So we'll also need to change the code in the app package so that it forwards the needed information to whatever pages want it. Obviously up to you how you do that forwarding. I.e. if you use parent.postMessage to ask for the information, or if you make the package app send the information as part of the URL when opening the marketplace.

Comment 2

[Gregor Wagner [:gwagner]]

(In reply to Wil Clouser [:clouserw] from comment #0)
> The feature detection API is going to be privileged for now which means
> we'll need to request the permission in the marketplace we ship with 1.3. 
> We should do this as soon as we can since their code is freezing.
> 
> We can do this before bug 983502 closes if we know what the permission is
> called and if requesting a non-existent permission is simply ignored by the
> client.
> 

Non-existing permissions will print a warning in logcat but it should still work.

Comment 3

[Wil Clouser [:clouserw]]

Thanks.  Ehsan (or anyone) - if you know what the permission will be called, let us know.

Comment 4

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

See comment 3

Comment 5

[(no longer active)]

(In reply to Wil Clouser [:clouserw] from comment #3)
> Thanks.  Ehsan (or anyone) - if you know what the permission will be called,
> let us know.

See https://wiki.mozilla.org/WebAPI/Navigator.hasFeature#Supported_feature_names please.

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

The question is what the *permission* will be called. I.e. what do you put in the manifest in order to get to use this API?

Comment 7

[[:fabrice] Fabrice Desré]

I vote for "feature-detection"

Comment 8

[Andreas Gal :gal]

Please re-triage. Explain why this has to block 1.3T. Could we solve this with a unique UA string? (thats common for devices anyway). Every 1.3T devices will have the same UA and the same hardware config.

Comment 9

[(no longer active)]

(In reply to Jonas Sicking (:sicking) from comment #6)
> The question is what the *permission* will be called. I.e. what do you put
> in the manifest in order to get to use this API?

Ah, sorry, I also vote for "feature-detection" as I suggested in bug 983502 comment 2.

Comment 10

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Andreas: I'd prefer to add the feature detection API discussed here. Using the UA-string is a more fragile workaround which we really should only use short-term. The feature detection API should be very simple and low-risk so I'd rather go that route.

But I agree that if we have any trouble getting the feature detection API in in time we should just adjust the UA-string.

Comment 11

[Andreas Gal :gal]

Risk for 1.3 and 1.3T is really high at this point. Can we do the brittle UA route for 1.3T and add this to 1.5? (the next update will be 1.3T -> 1.5).

Comment 12

[Wil Clouser [:clouserw]]

The Marketplace code flow isn't set up to look at UA at all (we send back feature flags, not UA flags) so we'd have to write that detection and conversion (UA X = these feature flags) and then maintain it going into the future.  It's error prone and doesn't scale.

In addition, this is a problem outside of Tarako as well because the methods we use for detection are being fixed and our ability to detect what devices can use is getting worse with every release.  This is why the LINE app "disappeared" from the Marketplace a couple weeks ago.

Comment 13

[Andreas Gal :gal]

We have about 8 months to fix the marketplace. We have about 2 weeks to fix 1.3T. I am not claiming that this will scale. I am claiming that it will scale to 1 use case for 1 device type so we don't have to blow our 1.3T risk budget and timeline.

Comment 14

[[:fabrice] Fabrice Desré]

(In reply to Wil Clouser [:clouserw] from comment #12)
> The Marketplace code flow isn't set up to look at UA at all (we send back
> feature flags, not UA flags) so we'd have to write that detection and
> conversion (UA X = these feature flags) and then maintain it going into the
> future.  It's error prone and doesn't scale.

But you had to do that to distinguish 1.1 (gecko 18.1) from 1.0 (gecko 18.0) right? How would this situation be different?

> In addition, this is a problem outside of Tarako as well because the methods
> we use for detection are being fixed and our ability to detect what devices
> can use is getting worse with every release.  This is why the LINE app
> "disappeared" from the Marketplace a couple weeks ago.

Sure, but that API will not be backported to anything but 1.3T (it will not be on 1.3 and 1.4) from 1.5.

So I would also like to not block, and would consider an uplift it that happens to be ready.

Comment 15

[Andreas Gal :gal]

Based on the discussion here this should go into 1.5. Once ready we can consider an uplift, but that seems unlikely.

Comment 16

[Caitlin Galimidi [:c8o]]

Andreas - 
Who should we be working with re: timelines? (program and / or product manager)
We've been hearing dates as early as June.

Who is my counterpart to coordinate the teams?

Comment 17

[Wil Clouser [:clouserw]]

> We have about 8 months to fix the marketplace. We have about 2 weeks to fix
> 1.3T. I am not claiming that this will scale. I am claiming that it will
> scale to 1 use case for 1 device type so we don't have to blow our 1.3T risk
> budget and timeline.

This may be a misunderstanding from me - the Marketplace is targeting June for having consumers using the Marketplace.  Is the phone going to market in November?  Link where I can see the timeline?

> > The Marketplace code flow isn't set up to look at UA at all (we send back
> > feature flags, not UA flags) so we'd have to write that detection and
> > conversion (UA X = these feature flags) and then maintain it going into the
> > future.  It's error prone and doesn't scale.
> 
> But you had to do that to distinguish 1.1 (gecko 18.1) from 1.0 (gecko 18.0)
> right? How would this situation be different?

I don't think we do because 1.0 never had enough usage to justify it.  I'll look into it though.

> > In addition, this is a problem outside of Tarako as well because the methods
> > we use for detection are being fixed and our ability to detect what devices
> > can use is getting worse with every release.  This is why the LINE app
> > "disappeared" from the Marketplace a couple weeks ago.
> 
> Sure, but that API will not be backported to anything but 1.3T (it will not
> be on 1.3 and 1.4) from 1.5.

Ah, that's a shame.  I'll drop that from here then as it doesn't seem relevant.


> Based on the discussion here this should go into 1.5. Once ready we can
> consider an uplift, but that seems unlikely.

I'm concerned that we made an announcement 3 weeks ago that we're focused on code quality but now that we're bumping up against a deadline we're not giving that affordance to the Marketplace team by having them maintain this admittedly brittle detection.  Temporary things at Mozilla easily become permanent things.  We've been talking about this for a year (bug 900241 & friends) and now you're bumping this to 1.5 - this was promised in (I think?) 1.2, and then 1.3, and now 1.5, and something else is going to be important when we're working on 1.5 and what's going to keep this from getting bumped again?

Comment 18

[Wil Clouser [:clouserw]]

Oh, meant to ask above:  what is the UA that Tarako is shipping with?

Comment 19

[Andreas Gal :gal]

We will have gecko 28 right? Would gecko 28.1 do?

Comment 20

[Wil Clouser [:clouserw]]

You mean match /Gecko 28\.1/ ?  I think that would work but I'm not super familiar with where we use our UAs so I can't say whether that would be used elsewhere.

Comment 21

[Wil Clouser [:clouserw]]

needinfo for comment 20.  I'm not sure if we're confirmed on that string yet or not.

Comment 22

[[:fabrice] Fabrice Desré]

(In reply to Wil Clouser [:clouserw] from comment #21)
> needinfo for comment 20.  I'm not sure if we're confirmed on that string yet
> or not.

Yeah, the patch is ready in my queue.

Comment 23

[Andreas Gal :gal]

See comment 22

Comment 24

[[:fabrice] Fabrice Desré]

The UA change patch is in bug 987450

Comment 25

[Jason Smith [:jsmith]]

Let's use the dependency here to track the blocking-b2g need here.

Comment 26

[David Bialer [:dbialer]]

Added spreadsheet for testing based on https://github.com/mozilla/fireplace/blob/95843c8/hearth/media/js/buckets.js#L52

Comment 27

[Andrew Williamson [:eviljeff]]

(In reply to David Bialer [:dbialer] from comment #26)
> Added spreadsheet for testing based on
> https://github.com/mozilla/fireplace/blob/95843c8/hearth/media/js/buckets.
> js#L52

do we want the manifest fields on the list too (bug 900241), even though they aren't currently detected?

Comment 28

[David Bialer [:dbialer]]

(In reply to Andrew Williamson [:eviljeff] from comment #27)
> (In reply to David Bialer [:dbialer] from comment #26)
> > Added spreadsheet for testing based on
> > https://github.com/mozilla/fireplace/blob/95843c8/hearth/media/js/buckets.
> > js#L52
> 
> do we want the manifest fields on the list too (bug 900241), even though
> they aren't currently detected?

Yes we do, but I am struggling on this.   If manifest fields are only detectable from 2.0 forward, the existing ones new fields would always be supported.  what we really want to do is test for any manifest field/value pairs - correct?

Comment 29

[Andrew Williamson [:eviljeff]]

(In reply to David Bialer [:dbialer] from comment #28)
> (In reply to Andrew Williamson [:eviljeff] from comment #27)
> > (In reply to David Bialer [:dbialer] from comment #26)
> > > Added spreadsheet for testing based on
> > > https://github.com/mozilla/fireplace/blob/95843c8/hearth/media/js/buckets.
> > > js#L52
> > 
> > do we want the manifest fields on the list too (bug 900241), even though
> > they aren't currently detected?
> 
> Yes we do, but I am struggling on this.   If manifest fields are only
> detectable from 2.0 forward, the existing ones new fields would always be
> supported.  

For the most part, yes (role would vary by platform).  Though as the feature-detection API will only be in 2.0 also, a lot of the features on the list will always be true too.

> what we really want to do is test for any manifest field/value pairs - correct?

yes (afaik)

Comment 30

[Wil Clouser [:clouserw]]

The blockers for this bug are closed and we can get moving on this!  Hooray, thanks for the help from everyone pushing on this.

Documentation for hasFeature/getFeature is at https://wiki.mozilla.org/WebAPI/Navigator.hasFeature

Due to the nature of this API and the desire that APIs become less privileged over time, items in this API may disappear and become accessible through regular methods instead of this API.  For the currently privileged APIs, it's suggested we use the API as follows:

> if ("push" in navigator) {
>   // navigator.push is available with the current set of permissions
> } else {
>   navigator.hasFeature("api.window.Navigator.push").then(function(val) {
>     if (val) {
>       // navigator.push exists in a higher privilege context
>     }
>   });
> }

There has been a lot of discussion and moving parts around this API so if something isn't clear please come ask me for Marketplace stuff or :ehsan for API questions.  Thanks!

Comment 31

[Wil Clouser [:clouserw]]

Removing priority until dbialer can sync up with people and get back to us.

Comment 32

[Mathieu Pillard [:mat]]

Note that I did play with the API, even though I haven't committed anything yet. Some feedback:

- It works :)

- It's for privileged apps only, it needs a permission. Which means it'll never be usable in a browser (Desktop, Android, Firefox OS outside our package, etc).

- This means we can only use feature detection on Firefox OS (and only if we are inside the package). We can't use the `if ("push" in navigator)` style of checking, because everytime something is absent, we don't know if it's because a lack of permissions/privileges in Marketplace or because the feature is really not there.

- I like the fact that it's an asynchronous API, but unfortunately with the way our feature detection works right now, we have to wait for all feature detection checks to return before making the first API call that returns apps, so we don't benefit from that.

- It'd be interesting, later in the future, to get more info about the hardware. Something like hardware.bluetooth, hardware.camera, etc - right now we can use this API to know if a phone has support for the bluetooth API but we don't know if the device actually has bluetooth capabilities.

Comment 33

[Mathieu Pillard [:mat]]

Another piece of feedback:

- This doesn't solve the problem of permissions change for some APIs. When an API goes from certified-apps only to privileged-apps only, we have no way to detect that. For instance, bluetooth is currently a certified API. If it were to become available to privileged apps, a developer could submit an app to Marketplace using that API, but we wouldn't be able to hide that app from devices running older versions of Firefox OS where this API is still only available for certified apps.