Closed
Bug 1036227
Opened 10 years ago
Closed 10 years ago
Get rid of dom.mobileconnection.enabled pref
Categories
(Core :: DOM: Device Interfaces, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: reuben, Assigned: reuben)
Details
Attachments
(1 file)
(deleted),
patch
|
Details | Diff | Splinter Review |
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).
Assignee | ||
Comment 1•10 years ago
|
||
Assignee: nobody → reuben.bmo
Comment 2•10 years ago
|
||
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?
Flags: needinfo?(reuben.bmo)
Assignee | ||
Comment 3•10 years ago
|
||
(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?
Flags: needinfo?(reuben.bmo) → needinfo?(vyang)
Comment 4•10 years ago
|
||
(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.
Flags: needinfo?(vyang)
Assignee | ||
Comment 5•10 years ago
|
||
Given bug 1009645 comment 56, we'll keep the pref and introduce a new WebIDL annotation.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•