If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Make sure interfaces implemented only for b2g don't show up in normal Firefox builds

NEW
Unassigned

Status

Firefox OS
General
5 years ago
5 years ago

People

(Reporter: smaug, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
The new stuff implemented only in b2g shouldn't show up at all in
normal Firefox builds.
Right now .navigator has for example .mozMobileConnection and .mozSms which shouldn't
be there. Also, interfaces used for those are visible in the global scope.
We shouldn't pollute global scope if possible.
We had this discussion a while ago and Jonas claimed the preferred method of feature detection is to return |null| from getters for unimplemented APIs.
(In reply to Olli Pettay [:smaug] from comment #0)
> The new stuff implemented only in b2g shouldn't show up at all in
> normal Firefox builds.
> Right now .navigator has for example .mozMobileConnection and .mozSms which
> shouldn't be there.

In addition to the point raised in comment 1, my I ask why? I would argue that we should strive to make Gecko -- wherever it runs -- behave as similarly as possible.

> Also, interfaces used for those are visible in the global scope.
> We shouldn't pollute global scope if possible.

I agree, but that seems like an entirely separate problem to me.
(Reporter)

Comment 3

5 years ago
(In reply to Philipp von Weitershausen [:philikon] from comment #2)
> > Also, interfaces used for those are visible in the global scope.
> > We shouldn't pollute global scope if possible.
> 
> I agree, but that seems like an entirely separate problem to me.
It is not. Interfaces need to be in the global scope. But it makes no sense to have them there
if there is no implementation for those.

If we want .mozMobileConnection to just return null in desktop FF, perhaps it should be
nsISupports. If MobileConnection has the correct classinfo, returning it as nsISupports should
still work on b2g.
That way we could hide interfaces on desktop (#ifdef out interfaces from desktop FF)

Comment 4

5 years ago
The API makes a lot of sense on Android as well. The web should appear consistent across devices. Whats the advantage of hiding this one particular API on the desktop? Jonas, what do you think?

Comment 5

5 years ago
Also, .mozSms makes a ton of sense on Android. It should most definitely not only be implemented on b2g.
(In reply to Andreas Gal :gal from comment #5)
> Also, .mozSms makes a ton of sense on Android. It should most definitely not
> only be implemented on b2g.

FTR, there is an Android implementation for that but it's not compiled (and highly bit-rotted now, I guess) because Android people are against WebSMS on Android.

Comment 7

5 years ago
They were against SMS at a specific time in the Android Native UI 1.0 release window, for a good reason I think. We should re-enable it and have it ride on the release train.
(Reporter)

Comment 8

5 years ago
(In reply to Andreas Gal :gal from comment #4)
> The API makes a lot of sense on Android as well. The web should appear
> consistent across devices. 
But it is not if we implement stuff only for certain devices (like only non-desktop).
For feature testing it is best to
not have any hints of APIs which aren't really implemented.

Comment 9

5 years ago
I think people disagree on that. I have seen a number of APIs return null when not present (intentionally). I am ok with either approach, as long its consistent.
(Reporter)

Comment 10

5 years ago
(In reply to Andreas Gal :gal from comment #9)
> I have seen a number of APIs return null
> when not present (intentionally). 
APIs such as?
Given that webdevelopers will have to do feature testing, having the object returning null or undefined is a small difference because most of the time, the test will be something like |if (navigator.mozSms)|. I understand that undefined would be better though.
Hmm.. sorry, i might have been unclear or have changed my mind.

I definitely think that it's better that features that we aren't shipping in a given build should result in properties that doesn't exist at all.

However in cases where a feature is disabled because a page doesn't have access to it, like mozSMS, I think it's better that the property exists but returns null since that shows some indication that the property exists on the platform but is disabled for one reason or another.
null or undefined I guess I should say. I don't feel strongly either way.
Blocks: 744714
Depends on: 785942
No longer blocks: 744714
Duplicate of this bug: 749834
Depends on: 795715
You need to log in before you can comment on or make changes to this bug.