1036227 - Get rid of dom.mobileconnection.enabled pref

Status: RESOLVED INVALID

(Core :: DOM: Device Interfaces, defect)

Description

[Reuben Morais [:reuben]]

The interfaces hiding behind the pref are a mix of things that are only enabled on MOZ_B2G_RIL anyway and things that are behind permissions. Removing the pref would allow us to include mozMobileConnections in the Navigator.getFeature list (bug 1009645).

Comment 1

[Reuben Morais [:reuben]]

Attachment: Get rid of the dom.mobileconnection.enabled pref

Comment 2

[Vicamo Yang [:vicamo][:vyang]]

Hi, two notes:

1) There are other prefs serving similar purposes: "dom.x.enabled" for x in "sms icc voicemail cellbroadcast telephony", so this would be better a change that applies to as many of them as possible. Not just mobileconnection.

2) Mounir had stated that we should avoid preprocessor guards as possible and there is a bug 947116 to eliminate MOZ_B2G_RIL usage. What we can do as the first step is to remove MOZ_B2G_RIL in DOM implementations and leave them guarded by "dom.foo.enabled" pref instead.  So, these two ideas are basically conflicting with each other. What's your proposal after removing these pref settings?

Comment 3

[Reuben Morais [:reuben]]

(In reply to Vicamo Yang [:vicamo][:vyang] from comment #2)
> 1) There are other prefs serving similar purposes: "dom.x.enabled" for x in
> "sms icc voicemail cellbroadcast telephony", so this would be better a
> change that applies to as many of them as possible. Not just
> mobileconnection.

Sure, I'm removing other similar prefs as well: bug 1036220, bug 1036222, etc.

> 2) Mounir had stated that we should avoid preprocessor guards as possible
> and there is a bug 947116 to eliminate MOZ_B2G_RIL usage. What we can do as
> the first step is to remove MOZ_B2G_RIL in DOM implementations and leave
> them guarded by "dom.foo.enabled" pref instead.  So, these two ideas are
> basically conflicting with each other. What's your proposal after removing
> these pref settings?

I want to use preprocessor guards instead of a pref because it makes my life harder over in bug 1009645 and because using a pref is silly if all you do with it is:

  #ifdef MOZ_B2G_RIL
  pref("foo", true);
  #else
  pref("foo", false);
  #endif

Is there a reason to avoid preprocessor guards?

Comment 4

[Vicamo Yang [:vicamo][:vyang]]

(In reply to Reuben Morais [:reuben] from comment #3)
> Is there a reason to avoid preprocessor guards?

Bug 947116 already has https://groups.google.com/forum/#!msg/mozilla.dev.b2g/EUK5cZp8KJo/i6ZcbgRYJzUJ . The main concept is to reduce built binary variants for easier security audition. So guarding RIL DOM implementation using MOZ_B2G_RIL is just _not_ preferred. Removing "dom.foo.enabled" is fine, but please don't put more duty on MOZ_B2G_RIL.

For backends, different platforms may have different implementations, so backends are guarded by both MOZ_B2G_RIL and MOZ_WIDGET_TOOLKIT for the time being. MOZ_B2G_RIL may be removed completely if it's no longer needed.

I'll go pick up the discussion on going in bug 1009645, and see if we can come out yet another solution for that.

Comment 5

[Reuben Morais [:reuben]]

Given bug 1009645 comment 56, we'll keep the pref and introduce a new WebIDL annotation.