859554 - Unimplemented Web APIs are stubbed out inappropriately

Status: RESOLVED INCOMPLETE

(Core :: DOM: Device Interfaces, defect)

Description

[Matt Basta [:basta]]

Web APIs that aren't implemented are present but null. This is the same as APIs which *are* implemented (on FXOS, for instance) but are not accessible due to a lack of permissions.

This prevents feature sniffing, which means that developers cannot gracefully degrade their user experience (they cannot detect when the browser will not support a feature). It also means that the Marketplace cannot detect when to hide apps that cannot run on the user's platform.

This may also be a bug with Firefox for Android.

This blocks a Q2 Marketplace goal.

Comment 1

[Jason Smith [:jsmith]]

Mounir - Any thoughts?

Comment 2

[Daniel Buchner [:dbuc]]

This is a hard stop for feature detection of APIs on the client. We cannot proceed without the APIs on navigator that are not implemented on a given platform variant (ex: contacts on desktop) either being removed from the object or returning an explicit undefined value - currently everything reports back null, even when it is not implemented.

Comment 3

[[:fabrice] Fabrice Desré]

Matt, do you have a list of APIs that you know behave like that?

Comment 4

[Matt Basta [:basta]]

The short list that I'm looking at is:

navigator.mozSms
navigator.mozContacts
navigator.mozPower
navigator.mozCameras
navigator.mozMobileMessage

All of the above APIs are present in FX Desktop Nightly.

Comment 5

[Daniel Buchner [:dbuc]]

(In reply to Matt Basta [:basta] from comment #4)
> The short list that I'm looking at is:
> 
> navigator.mozSms
> navigator.mozContacts
> navigator.mozPower
> navigator.mozCameras
> navigator.mozMobileMessage
> 
> All of the above APIs are present in FX Desktop Nightly.

This API behavior should be something that is observed for all existing and future additions to our runtime (which is how web APIs behave/are detected today)

Comment 6

[Jason Smith [:jsmith]]

(In reply to Matt Basta [:basta] from comment #0)
> Web APIs that aren't implemented are present but null. This is the same as
> APIs which *are* implemented (on FXOS, for instance) but are not accessible
> due to a lack of permissions.

The problem if I understand this is that we're combining the concept of "you don't have permissions to access this" and "this isn't supported on this platform." And you are asking for the concepts to be differentiated as I understand it, right?

> 
> This prevents feature sniffing, which means that developers cannot
> gracefully degrade their user experience (they cannot detect when the
> browser will not support a feature). It also means that the Marketplace
> cannot detect when to hide apps that cannot run on the user's platform.

I'm not sure you are necessarily blocked from figuring out when to hide apps here. There might be potential workarounds using the app metadata, for example.

> 
> This may also be a bug with Firefox for Android.

What you are describing would be a core issue across all platforms actually.

> 
> This blocks a Q2 Marketplace goal.

Dependent on my question above.

(In reply to Matt Basta [:basta] from comment #4)
> The short list that I'm looking at is:
> 
> navigator.mozSms
> navigator.mozContacts
> navigator.mozPower
> navigator.mozCameras
> navigator.mozMobileMessage
> 
> All of the above APIs are present in FX Desktop Nightly.

Anything that's a certified API isn't relevant to the analysis here. The scope here that really matters is anything that's privileged or lower.

Comment 7

[Matt Basta [:basta]]

(In reply to Jason Smith [:jsmith] from comment #6)
> The problem if I understand this is that we're combining the concept of "you
> don't have permissions to access this" and "this isn't supported on this
> platform." And you are asking for the concepts to be differentiated as I
> understand it, right?

Yes.

> I'm not sure you are necessarily blocked from figuring out when to hide apps
> here. There might be potential workarounds using the app metadata, for
> example.

We have no other way of determining whether a platform supports a web API or doesn't. If we know that an app uses the contacts API, but mozContacts is present but null on the device, how else can the Marketplace tell whether the platform supports the contacts API?

> Anything that's a certified API isn't relevant to the analysis here. The
> scope here that really matters is anything that's privileged or lower.

Can you guarantee that all apps that are presently certified will never become privileged APIs? If not, this argument isn't valid and still causes issues for the Marketplace.

Comment 8

[Jason Smith [:jsmith]]

(In reply to Matt Basta [:basta] from comment #7)
> (In reply to Jason Smith [:jsmith] from comment #6)
> > The problem if I understand this is that we're combining the concept of "you
> > don't have permissions to access this" and "this isn't supported on this
> > platform." And you are asking for the concepts to be differentiated as I
> > understand it, right?
> 
> Yes.
> 
> > I'm not sure you are necessarily blocked from figuring out when to hide apps
> > here. There might be potential workarounds using the app metadata, for
> > example.
> 
> We have no other way of determining whether a platform supports a web API or
> doesn't. If we know that an app uses the contacts API, but mozContacts is
> present but null on the device, how else can the Marketplace tell whether
> the platform supports the contacts API?

A not-so-nice workaround would require a lookup table stored on the marketplace side. Although I'm noting that this is a workaround to the problem.

> 
> > Anything that's a certified API isn't relevant to the analysis here. The
> > scope here that really matters is anything that's privileged or lower.
> 
> Can you guarantee that all apps that are presently certified will never
> become privileged APIs? If not, this argument isn't valid and still causes
> issues for the Marketplace.

No, but I wouldn't guarantee the APIs will necessarily be the same if they ever became privileged. Some may never get exposed. That's the case with mozCameras, for example.

Comment 9

[[:fabrice] Fabrice Desré]

We should just fix that properly, I don't see much value in heuristic hacks. If the list from comment 4 is what you need, please file a new bug for each one in the DOM/Device API component and mark them as blocking this one.

Comment 10

[Jason Smith [:jsmith]]

(In reply to Fabrice Desré [:fabrice] from comment #9)
> We should just fix that properly, I don't see much value in heuristic hacks.
> If the list from comment 4 is what you need, please file a new bug for each
> one in the DOM/Device API component and mark them as blocking this one.

Yeah, true. The hacks will get messy. I was analyzing this to see if there were any possibilities before calling a stop-ship blocker.

There's more APIs affected by this btw then just the ones Basta cites. We should do a scrub of the list of APIs and file bugs appropriately for any of them are affected (e.g. I know device storage is affected as well).

Comment 11

[Jason Smith [:jsmith]]

I'll hack a test case together quickly to analyze what API bugs we need here. If someone beats me to it, feel free to steal.

Comment 12

[Gregor Wagner [:gwagner]]

(In reply to Fabrice Desré [:fabrice] from comment #9)
> We should just fix that properly, I don't see much value in heuristic hacks.
> If the list from comment 4 is what you need, please file a new bug for each
> one in the DOM/Device API component and mark them as blocking this one.

Assign contacts to me. I guess settings has the same problem.
I already talked to mrbkap and bent about it and we know an easy fix.

Comment 13

[Daniel Buchner [:dbuc]]

(In reply to Fabrice Desré [:fabrice] from comment #9)
> We should just fix that properly, I don't see much value in heuristic hacks.
> If the list from comment 4 is what you need, please file a new bug for each
> one in the DOM/Device API component and mark them as blocking this one.

While a case-by-case examination of the existing set of APIs seems to be the answer for our immediate needs, can we make this part of a larger API development process/requirement? Perhaps a general policy for platform API development that defines how objects/methods should be attached, or the value thereof, when the API in question is not implemented in a particular environment?

Comment 14

[Jason Smith [:jsmith]]

(In reply to Daniel Buchner [:dbuc] from comment #13)
> (In reply to Fabrice Desré [:fabrice] from comment #9)
> > We should just fix that properly, I don't see much value in heuristic hacks.
> > If the list from comment 4 is what you need, please file a new bug for each
> > one in the DOM/Device API component and mark them as blocking this one.
> 
> While a case-by-case examination of the existing set of APIs seems to be the
> answer for our immediate needs, can we make this part of a larger API
> development process/requirement? Perhaps a general policy for platform API
> development that defines how objects/methods should be attached, or the
> value thereof, when the API in question is not implemented in a particular
> environment?

Sounds like a good case for an automated test case in the WebAPI permissions test cases.

Comment 15

[Jason Smith [:jsmith]]

Changing this to a meta bug. I'll file dependent bugs on a per API basis.

Comment 16

[Gregor Wagner [:gwagner]]

Do we have to uplift all fixes?

Comment 17

[Jason Smith [:jsmith]]

(In reply to Gregor Wagner [:gwagner] from comment #16)
> Do we have to uplift all fixes?

For desktop and android, yeah, I'd uplift to Aurora at a minimum. For b2g, it's not required, but probably worthwhile to uplift to b2g18 to ensure that the code is consistent.

Comment 18

[David Bruant]

Discussion on this topic, also happened as part of bug 838614. Comment 7 there is relevant https://bugzilla.mozilla.org/show_bug.cgi?id=838614#c7

Comment 19

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

FxOS/Gonk has been removed from the codebase. Mass-invalidating FxOS related Device Interface bugs to clean up the component. 

If I incorrectly invalidated something, please let me know.

Comment 20

[Firefox Bug Husbandry Bot]

Bulk correction of resolution of B2G bugs to INCOMPLETE.