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.
(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)
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?
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.
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.
(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.
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.
(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.
7 years ago
Duplicate of this bug: 749834
Firefox OS is not being worked on
Status: NEW → RESOLVED
Last Resolved: 11 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.