Closed Bug 962656 Opened 11 years ago Closed 10 years ago

Correctly detect 3rd party keyboard support feature

Categories

(Firefox OS Graveyard :: General, defect, P2)

Product:
Firefox OS Graveyard
Component:
General
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 1009645
Milestone:
2.0 S3 (6june)

People

(Reporter: eviljeff, Assigned: timdream)

References

Details

The feature/buchet detection implemented in bug 925820 and bug 922209 depends on window.navigator.mozInputMethod being available but that is present in 1.2, whereas Gaia support for selecting 3rd party keyboards doesn't exist until 1.4.
We need to fix this before we can approve any 3rd party keyboards.
Let me investigate.
Assignee: nobody → timdream
Hi Andrew,

With some offline discussion, we realized there isn't a easy solution here. To make the feature detection work again we must explicitly made a DOM API change on |navigator| node. I don't think Marketplace app will be able to detect new API method inside |window.navigator.mozInputMethod| even if we introduce a new one there (due to lack of permission).

Is it possible to fallback to Gecko version # detection? It sucks but I don't think there is a better way.
Flags: needinfo?(awilliamson)
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #2)
> Is it possible to fallback to Gecko version # detection? It sucks but I
> don't think there is a better way.

No.   See https://bugzilla.mozilla.org/show_bug.cgi?id=895474 for a long discussion of what happened last time there were undetectable platform changes made.
Flags: needinfo?(awilliamson)
Thanks.

After an offline discussion, it looks like our only option would be change the property name under navigator. Instead of trying to figuring out another name, Kanru have suggested that we could unprefix it with Jonas' blessing.

Background:
1. We shipped mozInputMethod API in FxOS 1.2 but we disabled the feature in Gaia.
2. We intend to enable the feature in FxOS 1.4.
3. Marketplace need an API to do feature detection, and the current situation makes it impossible to tell between phones with the feature and without.
4. mozInputMethod API is a privileged-only API. It does not expose to the general web.

Jonas, are we allow to do so? Does this action fits https://wiki.mozilla.org/WebAPI/ExposureGuidelines ?
Jonas, please read comment above. We need your opinion on un-prefixing the mozInputMethod API.
Flags: needinfo?(jonas)
(In reply to Andrew Williamson [:eviljeff] from comment #3)
> (In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from
> comment #2)
> > Is it possible to fallback to Gecko version # detection? It sucks but I
> > don't think there is a better way.
> 
> No.   See https://bugzilla.mozilla.org/show_bug.cgi?id=895474 for a long
> discussion of what happened last time there were undetectable platform
> changes made.

Can we do that in addition to checking for navigator.mozInputMethod's existence?
(In reply to :Ehsan Akhgari (needinfo? me!) (slow responsiveness, emailacopolypse) from comment #6)
> (In reply to Andrew Williamson [:eviljeff] from comment #3)
> > (In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from
> > comment #2)
> > > Is it possible to fallback to Gecko version # detection? It sucks but I
> > > don't think there is a better way.
> > 
> > No.   See https://bugzilla.mozilla.org/show_bug.cgi?id=895474 for a long
> > discussion of what happened last time there were undetectable platform
> > changes made.
> 
> Can we do that in addition to checking for navigator.mozInputMethod's
> existence?

That's what Tim was suggesting in comment #2 and wouldn't be good for the reasons mentioned in bug 895474
If I'm getting Ehsan's comment right, he's suggesting we blacklist the bad FxOS versions. If `navigator.mozInputMethod` is present it _should_ work but there are some bad implementations we need to ignore.
Priority: -- → P2
(In reply to Mark Striemer [:mstriemer] from comment #8)
> If I'm getting Ehsan's comment right, he's suggesting we blacklist the bad
> FxOS versions. If `navigator.mozInputMethod` is present it _should_ work but
> there are some bad implementations we need to ignore.

Yes, that's what I was suggesting.
(In reply to :Ehsan Akhgari (needinfo? me!) (slow responsiveness, emailacopolypse) from comment #9)
> (In reply to Mark Striemer [:mstriemer] from comment #8)
> > If I'm getting Ehsan's comment right, he's suggesting we blacklist the bad
> > FxOS versions. If `navigator.mozInputMethod` is present it _should_ work but
> > there are some bad implementations we need to ignore.
> 
> Yes, that's what I was suggesting.

Andrew, would this address your concerns?  Thanks!
Flags: needinfo?(awilliamson)
(In reply to :Ehsan Akhgari (needinfo? me!) (slow responsiveness, emailacopolypse) from comment #10)
> (In reply to :Ehsan Akhgari (needinfo? me!) (slow responsiveness,
> emailacopolypse) from comment #9)
> > (In reply to Mark Striemer [:mstriemer] from comment #8)
> > > If I'm getting Ehsan's comment right, he's suggesting we blacklist the bad
> > > FxOS versions. If `navigator.mozInputMethod` is present it _should_ work but
> > > there are some bad implementations we need to ignore.
> > 
> > Yes, that's what I was suggesting.
> 
> Andrew, would this address your concerns?  Thanks!

The current school of thought is that any detection of gecko version from the UA is risky and prone to breakage, and generally anti-feature-detection.  I can see how in this case its only covering an edge case though.  In the end its a decision for Wil's team.
Flags: needinfo?(awilliamson)
I would argue it's a edge case too... there are no keyboard app in marketplace currently, and there are likely not that many in near future since there is higher bar for building a reasonable good keyboard, compare to usual web apps.

There are some other non-public reasons supporting the argument here too.

Anyhow, Wil, is it possible to make a decision here to use UA version detection?
Flags: needinfo?(clouserw)
I'm going to make a call here.

I don't think there's good enough reasons to change anything on the platform side here:

1. Property detection isn't how privileged APIs should be detected anyway. The fact that navigator.mozInputMethod ever returns a non-null value for the marketplace is a bug. Privileged APIs should be hidden from pages that don't have access to them. That includes marketplace pages.

I.e. it has been requested that "'foo' in navigator" should return false if the page doesn't have access to the 'foo' API.

So any detection of navigator.mozInputMethod isn't going to be a final solution anyway.

2. Blacklisting versions is a whole lot less worse than whitelisting. The problem with whitelisting is that it's a pain to maintain correctly and always ends up excluding new players. Neither of these problems exist with blacklisting.
Flags: needinfo?(jonas)
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #12)
> I would argue it's a edge case too... there are no keyboard app in
> marketplace currently, and there are likely not that many in near future
> since there is higher bar for building a reasonable good keyboard, compare
> to usual web apps.

There aren't any keyboard apps because we've held them back from approval pending resolution of this bug.  There are 3 in the escalation queue right now (plus your test keyboard app)
(In reply to Jonas Sicking (:sicking) from comment #13)
> 1. Property detection isn't how privileged APIs should be detected anyway.
> The fact that navigator.mozInputMethod ever returns a non-null value for the
> marketplace is a bug. Privileged APIs should be hidden from pages that don't
> have access to them. That includes marketplace pages.

What is the recommended way to detect privileged API support on device?
needinfo for comment 15.  This is a pretty critical part of how the marketplace knows how to offer apps...
Flags: needinfo?(clouserw) → needinfo?(jonas)
Over in bug 838614 I was arguing that the way to check for support for privileged APIs was to use something like

if ('foo' in navigator) {
 <foo API supported>
}

However I was talked out of that as it was considered non-javascripty.

Instead the proposed solution is the one debated in bug 900241. I.e. add an API like

if (navigator.hasFeature("api.Navigator.foo")) {
 <foo API supported>
}

Until we have that bug, the only solution that we have that works consistently across APIs is unfortunately UA version detection :(
Flags: needinfo?(jonas)
(In reply to Jonas Sicking (:sicking) from comment #17)
> Until we have that bug, the only solution that we have that works
> consistently across APIs is unfortunately UA version detection :(

We were told there would be an API for feature detection in, I think, 1.2?  That it keeps slipping doesn't mean we should support UA filtering/blacklisting/whitelisting/whatever on the server side.  It needs to be prioritized and it needs to land.  I thought we all agreed on that last year.  How do we make sure it lands ASAP?
(In reply to Jonas Sicking (:sicking) from comment #17)
> Instead the proposed solution is the one debated in bug 900241. I.e. add an
> API like
> 
> if (navigator.hasFeature("api.Navigator.foo")) {
>  <foo API supported>
> }

Bug 900241 specifically talks about manifest feature detection.  Has there been prior discussion about the use case for detecting API availability elsewhere in Bugzilla or on a public list?
Flags: needinfo?(jonas)
I don't think we should unprefix. Instead we should implement the hasFeature API discussed in bug 900241 comment 22
Flags: needinfo?(jonas)
(In reply to Jonas Sicking (:sicking) from comment #20)
> I don't think we should unprefix. Instead we should implement the hasFeature
> API discussed in bug 900241 comment 22

In this case, this bug will be dependent on bug 900241 and both bug will receiving blocking+ on whatever version of FxOS we commit to support 3rd-party keyboard apps in marketplace.

And I setting the expectation correctly? Which team should be responsible of working on bug 900241?

Looping Ivay for the cross-team dependencies.
Depends on: 900241
Flags: needinfo?(itsay)
> And I setting the expectation correctly?

Yup. Sounds like a good plan.

> Which team should be responsible of working on bug 900241?

I think Ehsan has some ideas, but help is always appreciated. We're sadly very short on developers that can do generic gecko hacking for B2G :(
(In reply to comment #22)
> I think Ehsan has some ideas, but help is always appreciated. We're sadly very
> short on developers that can do generic gecko hacking for B2G :(

FWIW the API is currently under discussion on dev-webapi.  Once we know more about what it's going to look like, we can discuss the implementation plan.
Depends on: 983502
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #21)
> (In reply to Jonas Sicking (:sicking) from comment #20)
> > I don't think we should unprefix. Instead we should implement the hasFeature
> > API discussed in bug 900241 comment 22
> 
> In this case, this bug will be dependent on bug 900241 and both bug will
> receiving blocking+ on whatever version of FxOS we commit to support
> 3rd-party keyboard apps in marketplace.
> 
> And I setting the expectation correctly? Which team should be responsible of
> working on bug 900241?
> 
> Looping Ivay for the cross-team dependencies.

Currently the implementation work is in bug 983502. I will monitor bug 983502 for the dependency.
Flags: needinfo?(itsay)
Depends on: 1009645
No longer depends on: 983502
With 983502 complete, how do we move this forward?  Will getFeature work with api.window.Navigator.mozInputMethod to detect if 3rd party keyboards are supported, or was that not the original purpose of the name?
Flags: needinfo?(ehsan)
(In reply to Bruce Huang [:bhuang] <bhuang@mozilla.com> from comment #25)
> With 983502 complete, how do we move this forward?

That bug didn't actually implement the interesting parts of that API.  I've filed bug 1009645 for that, and have already fixed the dependency on this bug.

>  Will getFeature work
> with api.window.Navigator.mozInputMethod to detect if 3rd party keyboards
> are supported, or was that not the original purpose of the name?

Yes, it will.  Please see <https://wiki.mozilla.org/WebAPI/Navigator.hasFeature#.22api.22_namespace> for the list of supported names in the "api" namespace for getFeature.
Flags: needinfo?(ehsan)
Sorry Ehsan, I still don't understand how feature detection is done. So for 3rd-party keyboard support, since the InputMethod API is shipped on the platform, detecting the API along can't tell you whether or not the app will work. Incidentally, the feature is controlled by a mozSettings key: "keyboard.3rd-party-app.enabled", so we have the following choices:

A) re-route the "api.window.Navigator.mozInputMethod" keyword to the settings key.
B) create a new key for the detection, maybe even a new namespace.

I am also not sure about what work bug 1009645 represents. Is it just the baseline code to check for an API so we must do (A) or (B) here? Or is it covers (A)?
Component: Validation → General
Flags: needinfo?(ehsan)
Product: Marketplace → Firefox OS
Version: 1.0 → unspecified
(Throw to General before we figure out the scope of each bug)
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #27)
> Sorry Ehsan, I still don't understand how feature detection is done. So for
> 3rd-party keyboard support, since the InputMethod API is shipped on the
> platform, detecting the API along can't tell you whether or not the app will
> work. Incidentally, the feature is controlled by a mozSettings key:
> "keyboard.3rd-party-app.enabled", so we have the following choices:
> 
> A) re-route the "api.window.Navigator.mozInputMethod" keyword to the
> settings key.
> B) create a new key for the detection, maybe even a new namespace.

Hmm..  I'm not familiar with the mozSetting key you're mentioning above, and I was under the impression that this bug is requesting a way to allow the MarketPlace app to detect whether the platform supports the mozInputMethod API.  But you seem to be suggesting that this is not what this bug is about... :/

Can you please tell me what is the thing that we want to do here?  Note that I've read this bug a couple of times and so far everything seems to suggest that it's about detecting the presence of the API, so that is what I have been assuming so far.

> I am also not sure about what work bug 1009645 represents. Is it just the
> baseline code to check for an API so we must do (A) or (B) here? Or is it
> covers (A)?

But 1009645 will allow you to call navigator.getFeature("api.window.Navigator.mozInputMethod") and get a promise back which tells you whether the mozInputMethod API is supported on the platform without requiring you to have the permission to call it.  That should give the MarketPlace app the same ability to feature detect this as the existing code <https://github.com/mozilla/fireplace/blob/95843c8/hearth/media/js/buckets.js#L101> does.
Flags: needinfo?(ehsan)
Flags: needinfo?(timdream)
(In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment #29)
> (In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from
> comment #27)
> > Sorry Ehsan, I still don't understand how feature detection is done. So for
> > 3rd-party keyboard support, since the InputMethod API is shipped on the
> > platform, detecting the API along can't tell you whether or not the app will
> > work. Incidentally, the feature is controlled by a mozSettings key:
> > "keyboard.3rd-party-app.enabled", so we have the following choices:
> > 
> > A) re-route the "api.window.Navigator.mozInputMethod" keyword to the
> > settings key.
> > B) create a new key for the detection, maybe even a new namespace.
> 
> Hmm..  I'm not familiar with the mozSetting key you're mentioning above, and
> I was under the impression that this bug is requesting a way to allow the
> MarketPlace app to detect whether the platform supports the mozInputMethod
> API.  But you seem to be suggesting that this is not what this bug is
> about... :/
> 

No :P the purpose of this bug is to deal with detecting this "Gaia" feature. It's a bit complex than simply detect the API.

> Can you please tell me what is the thing that we want to do here?  Note that
> I've read this bug a couple of times and so far everything seems to suggest
> that it's about detecting the presence of the API, so that is what I have
> been assuming so far.

We want to be able to tell marketplace that this Gaia will be able to accept 3rd-party keyboard installation or not. Gecko have the knowledge stored in the mozSettings key.

> > I am also not sure about what work bug 1009645 represents. Is it just the
> > baseline code to check for an API so we must do (A) or (B) here? Or is it
> > covers (A)?
> 
> But 1009645 will allow you to call
> navigator.getFeature("api.window.Navigator.mozInputMethod") and get a
> promise back which tells you whether the mozInputMethod API is supported on
> the platform without requiring you to have the permission to call it.  That
> should give the MarketPlace app the same ability to feature detect this as
> the existing code
> <https://github.com/mozilla/fireplace/blob/95843c8/hearth/media/js/buckets.
> js#L101> does.

Right. So that's unfortunately not enough for Marketplace.

Could you suggest a proper way to proceed? Maybe (B) in comment 27 for the sake of symmetry?
Flags: needinfo?(timdream)
After reading the comment above,
I think we can do the thing similar to how we support getFeature(hardware.memory) in bug 983502.

In getFeature function,

if (aName.EqualsLiteral("hardware.memory") {
  ...
} else if (aName.EqualsLiteral("api.window.Navigator.mozInputMethod") {
  /* Read keyboard.3rd-party-app.enabled to determine how to resove the promise*/
  ...
}

Does this make sense to you?
Flags: needinfo?(timdream)
Flags: needinfo?(ehsan)
Sounds doable, Ehsan?
Flags: needinfo?(timdream)
No, I don't think I'd like to add more feature arguments to this API without understanding why they are needed.  I'm still not sure if I understand what determines whether gaia supports third party keyboards or not, but it seems like that decision is encoded in a mozSetting from comment 30, in which case, the work being done in bug 846200 should be enough for the MarketPlace app to read the setting directly without us having to modify getFeature() in any way.  Would that be enough for this use case?
Flags: needinfo?(ehsan) → needinfo?(timdream)
I can't speak for Marketplace team on that.
Flags: needinfo?(timdream) → needinfo?(awilliamson)
I'd like to add support for hasFeature/getFeature("api.window.Navigator.mozInputMethod"). Using the settings API seems like a bad workaround. Let's instead implement the property solution and then tell the marketplace team to use that.

Why do we even have a "keyboard.3rd-party-app.enabled" setting? Why would users want the ability to disable installing 3rd party keyboards?
(In reply to Jonas Sicking (:sicking) from comment #35)
> I'd like to add support for
> hasFeature/getFeature("api.window.Navigator.mozInputMethod"). Using the
> settings API seems like a bad workaround. Let's instead implement the
> property solution and then tell the marketplace team to use that.

We will have that support. The problem is that (as comment 0 stated) detecting the API along does not fulfill the use case.

> Why do we even have a "keyboard.3rd-party-app.enabled" setting? Why would
> users want the ability to disable installing 3rd party keyboards?

Well, I was asked to make the feature pref-able. "pref-able" in Gaia means having a hidden key in mozSettings. The user has no access to the settings (in fact, if they do, system app will have it's state messed up if the switch is flipped on runtime).
The type of preffable referred to is likely just a gecko pref, not a Gaia setting. We often enable turning off features through a gecko pref in case we last minute find some terrible bug in it, for example a security bug. So I don't think we need a gaia setting here.

So what I think we need here is simply to add

} else if (aName.EqualsLiteral("api.window.Navigator.mozInputMethod") {
  p->MaybeResolve(Preferences::GetBool("dom.keyboardapi.enabled", false));
}

It doesn't need to be more complicated than that.
Actually, potentially we should do:


} else if (aName.EqualsLiteral("api.window.Navigator.mozInputMethod") &&
           Preferences::GetBool("dom.keyboardapi.enabled", false)) {
  p->MaybeResolve(true);
}

That way we still resolve to 'undefined' if the feature is preffed off.
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #34)
> I can't speak for Marketplace team on that.

Personally, it seems cleaner to have all feature detection done via the feature detection API.  3rd party keyboards aren't the only gaia (rather than gecko) feature that may need to be detected and some may not have an equivalent setting to read.  But, it would work (in this case at least) if bug 846200 is decided on as the quick fix.
Flags: needinfo?(awilliamson)
(In reply to Jonas Sicking (:sicking) from comment #37)
> The type of preffable referred to is likely just a gecko pref, not a Gaia
> setting. We often enable turning off features through a gecko pref in case
> we last minute find some terrible bug in it, for example a security bug. So
> I don't think we need a gaia setting here.
> 
> So what I think we need here is simply to add
> 
> } else if (aName.EqualsLiteral("api.window.Navigator.mozInputMethod") {
>   p->MaybeResolve(Preferences::GetBool("dom.keyboardapi.enabled", false));
> }
> 
> It doesn't need to be more complicated than that.

We cannot pref off the API in Gecko because the built-in keyboard is using it. So, again, we are looking at detecting what's "pref off" in Gaia/mozSettings, and "shipped" (v1.2 & v1.3).
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #40)
> (In reply to Jonas Sicking (:sicking) from comment #37)
> > The type of preffable referred to is likely just a gecko pref, not a Gaia
> > setting. We often enable turning off features through a gecko pref in case
> > we last minute find some terrible bug in it, for example a security bug. So
> > I don't think we need a gaia setting here.
> > 
> > So what I think we need here is simply to add
> > 
> > } else if (aName.EqualsLiteral("api.window.Navigator.mozInputMethod") {
> >   p->MaybeResolve(Preferences::GetBool("dom.keyboardapi.enabled", false));
> > }
> > 
> > It doesn't need to be more complicated than that.

With the model that I've suggested in bug 1009645 comment 0, we won't need any of this magic.  IOW, the current proposal to implement the api namespace of getFeature() takes care of these types of API detections obviously.  The complication here comes from how (and if) we should handle the setting that Tim is mentioning.

> We cannot pref off the API in Gecko because the built-in keyboard is using
> it. So, again, we are looking at detecting what's "pref off" in
> Gaia/mozSettings, and "shipped" (v1.2 & v1.3).

Do you expect this setting to be used to disable the API going forward though, sans any last minute security problems like Jonas mentioned?  Those older releases will not have support for getFeature() anyway, so unless we expect the users of our devices being able to set the setting to false (which is what I was assuming!) then there is no need to check the setting at all, it seems.
Flags: needinfo?(timdream)
(In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment #41)
> > We cannot pref off the API in Gecko because the built-in keyboard is using
> > it. So, again, we are looking at detecting what's "pref off" in
> > Gaia/mozSettings, and "shipped" (v1.2 & v1.3).
> 
> Do you expect this setting to be used to disable the API going forward
> though, sans any last minute security problems like Jonas mentioned?  Those
> older releases will not have support for getFeature() anyway, so unless we
> expect the users of our devices being able to set the setting to false
> (which is what I was assuming!) then there is no need to check the setting
> at all, it seems.

You made a good point that getFeature() will not exists in these versions anyway, so we are safe in terms of filtering these versions out.

I don't expect that being switch off in future version. However, there is still a possibility that the feature is switch off on Gecko w/ getFeature() if

* we are on low-memory phones, where running two oop foreground apps results bad user experiences
* the feature again stay pref off for 2.0.

The fact that we are pref-off a feature from Gaia is indeed flawed. If the above case indeed happen, I think we should instead move that to Gecko (and restrict mozInputMethod to certified app when pref off is in effect). Does that make sense?
Flags: needinfo?(timdream)
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #42)
> (In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment
> #41)
> > > We cannot pref off the API in Gecko because the built-in keyboard is using
> > > it. So, again, we are looking at detecting what's "pref off" in
> > > Gaia/mozSettings, and "shipped" (v1.2 & v1.3).
> > 
> > Do you expect this setting to be used to disable the API going forward
> > though, sans any last minute security problems like Jonas mentioned?  Those
> > older releases will not have support for getFeature() anyway, so unless we
> > expect the users of our devices being able to set the setting to false
> > (which is what I was assuming!) then there is no need to check the setting
> > at all, it seems.
> 
> You made a good point that getFeature() will not exists in these versions
> anyway, so we are safe in terms of filtering these versions out.
> 
> I don't expect that being switch off in future version. However, there is
> still a possibility that the feature is switch off on Gecko w/ getFeature()
> if
> 
> * we are on low-memory phones, where running two oop foreground apps results
> bad user experiences

If we decide to do this, MarketPlace can detect that through navigator.getFeature("hardware.memory") AFAICT.

> * the feature again stay pref off for 2.0.

In this case we would probably want to remove [FeatureDetectible] from mozInputMethod in the WebIDL for 2.0 to just make getFeature() return undefined for that interface, which would be the result if the API were unsupported.

> The fact that we are pref-off a feature from Gaia is indeed flawed. If the
> above case indeed happen, I think we should instead move that to Gecko (and
> restrict mozInputMethod to certified app when pref off is in effect). Does
> that make sense?

Yes, I think it does!  FWIW if we need to write custom code in order to handle detecting whether this is available on the Gecko side so that getFeature() just returns the right thing, we can do that, but it seems to me that we should be able to just remove [FeatureDetectible] like I suggested above in case this doesn't make it for 2.0.

So with the above, do we need to keep this bug open?  It seems like there is no work that needs to happen here beyond bug 1009645.  Thanks!
Yeah. Thanks everyone for pitching in ideas.

If comment 42 happens let's file another bug for it.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Target Milestone: --- → 2.0 S3 (6june)
Ah, good point that we can't disable the full API though the gecko pref.

But I still don't think there's a need for a gaia setting. A simpler solution is to make the "dom.keyboardapi.enabled" gecko-pref (or whatever we'll call it) simply disable the ability for privileged apps to use the keyboard API. That way the code in comment 38 would work.
(In reply to Jonas Sicking (:sicking) from comment #45)
> Ah, good point that we can't disable the full API though the gecko pref.
> 
> But I still don't think there's a need for a gaia setting. A simpler
> solution is to make the "dom.keyboardapi.enabled" gecko-pref (or whatever
> we'll call it) simply disable the ability for privileged apps to use the
> keyboard API. That way the code in comment 38 would work.

Yes, agreed.  We can definitely do that if needed.
Andrew - is this going to work for you and your team?  If not, would you schedule a meeting with myself, Ehsan, and Jonas (I'm assuming you can't get Tim in your timezone).  I'm a bit lost here as I don't know too much about gecko prefs and such but I want to make sure we're completing this as needed.  Thanks.
Flags: needinfo?(awilliamson)
I'm not 100% clear myself... but I think it will work.  Tim, I'm understanding this as Marketplace will be able to detect if 3rd party keyboards are supported by doing: 

navigator.getFeature("api.window.Navigator.mozInputMethod")

which will return true if the device supports 3rd party keyboards, i.e. in FxOS 2.0+, but not on Desktop Firefox, etc (and would have returned false in 1.4 and below, if .getFeature existed). Once bug 10009645 is implemented, will that be correct?
Flags: needinfo?(awilliamson) → needinfo?(timdream)
It should also return false on configurations where we can't run oop keyboards like tarako.
(In reply to Andrew Williamson [:eviljeff] from comment #48)
> I'm not 100% clear myself... but I think it will work.  Tim, I'm
> understanding this as Marketplace will be able to detect if 3rd party
> keyboards are supported by doing: 
> 
> navigator.getFeature("api.window.Navigator.mozInputMethod")
> 
> which will return true if the device supports 3rd party keyboards, i.e. in
> FxOS 2.0+, but not on Desktop Firefox, etc (and would have returned false in
> 1.4 and below, if .getFeature existed). Once bug 10009645 is implemented,
> will that be correct?

if (!navigator.getFeature) {
  return false; // FxOS < 2.0, never mind
} else if (navigator.getFeature("api.window.Navigator.mozInputMethod")) {
  return true; // FxOS >= 2.0 and has the API enabled AND the feature enabled.
}

comment 42, comment 43, comment 45, comment 46, and comment 49 are talking about a possible scenario where we ship a FxOS >= 2.0 w/o the feature enabled. In this case we should have a Gecko pref to restrict the API to certified-app only level, and the feature will be disabled accordingly.

In other words, |navigator.getFeature("api.window.Navigator.mozInputMethod")| not only implies the API exists, it also means 3rd-party apps has access to it.

If filing that bug now makes everyone feel more comfortable, I am happy to do so.
Flags: needinfo?(timdream)
... and let's make the Gecko pref named "dom.mozInputMethod.certified-only" since the pref to enable the API is "dom.mozInputMethod.enabled"?
Blocks: 1035380
Blocks: 1047100
No longer blocks: 1047100
You need to log in before you can comment on or make changes to this bug.