Closed Bug 859554 Opened 11 years ago Closed 6 years ago

Unimplemented Web APIs are stubbed out inappropriately

Categories

(Core :: DOM: Device Interfaces, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: basta, Unassigned)

References

Details

(Keywords: meta)

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.
Component: Web Apps → DOM
Product: Firefox → Core
QA Contact: jsmith
Mounir - Any thoughts?
Flags: needinfo?(mounir)
Version: unspecified → Trunk
blocking-b2g: --- → tef?
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.
Matt, do you have a list of APIs that you know behave like that?
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.
(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)
(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.
(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.
(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.
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.
(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).
Flags: needinfo?(mounir)
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.
Keywords: qawanted
QA Contact: 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.

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.
(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?
(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.
Changing this to a meta bug. I'll file dependent bugs on a per API basis.
blocking-b2g: tef? → ---
Keywords: meta
Depends on: 859601
Depends on: 859610
Depends on: 859612
Depends on: 859614
Depends on: 859615
Depends on: 859616
Component: DOM → DOM: Device Interfaces
Depends on: 859623
Depends on: 859624
Depends on: 859626
Depends on: 859627
No longer depends on: 859623
No longer depends on: 859627
No longer depends on: 859601
No longer depends on: 859626
No longer depends on: 859624
Keywords: qawanted
Depends on: 859601
Do we have to uplift all fixes?
(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.
Blocks: 858314
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
Depends on: 838614
Depends on: 874263
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.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID
Bulk correction of resolution of B2G bugs to INCOMPLETE.
Resolution: INVALID → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.