887157 - Be able to enable/disable all wap push SI and SL

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::System::Lockscreen, defect)

Description

[Ken Chang[:kenkai]]

As a user I expect to be able to enable/disable all wap push services/options independent of what the carrier customization is.

Comment 1

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

Based on current structure, gecko receives wap push message(And might decode some standard message like SI and SL), then notify gaia with message directly.
The corresponding service/options are provided by app, and if the user story is about changing these settings, it should supported by app.

Or if the user story is saying "User can enable/disable the notification of wap push reception, and we have to provide a white list of wap push type, defined by carrier, that can always send reception notification regardless of the setting"?

Comment 2

[Ken Chang[:kenkai]]

I don't think it is appropriate to implement it in Gaia. This customization should be considered as a system level configuration, which means "User can disable or enable WAP push(In reply to Chuck Lee [:chucklee] from comment #1)
> Based on current structure, gecko receives wap push message(And might decode
> some standard message like SI and SL), then notify gaia with message
> directly.
> The corresponding service/options are provided by app, and if the user story
> is about changing these settings, it should supported by app.
> 
It makes sense to me, let's talk with Gaia dev.

Comment 3

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

(In reply to Ken Chang from comment #2)
> I don't think it is appropriate to implement it in Gaia. This customization
> should be considered as a system level configuration, which means "User can
> disable or enable WAP push

I think we have to clarify the "disable" implies "disable gecko from sending wap push system message" or "disable certain app from handling wap push message".
The prior is adding a setting, and later is adding a permission for wap push.

Comment 4

[Ken Chang[:kenkai]]

Gabriele, what do you think?

Comment 5

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

For the same reason as bug 887156 comment 8, I think this can also be handled by app itself.
We don't have to provide such settings/API, but add a permission for wap push might be necessary.

Comment 6

[Gabriele Svelto [:gsvelto]]

(In reply to Chuck Lee [:chucklee] from comment #5)
> For the same reason as bug 887156 comment 8, I think this can also be
> handled by app itself.
> We don't have to provide such settings/API, but add a permission for wap
> push might be necessary.

That would be the easy way but the story points to the fact that the user might want to disable WAP Push entirely - irrespective of what the carrier thinks. If that's the case then we need to add an appropriate option that blocks Gecko from delivering WAP Push messages and add the relevant switch in the Settings app.

I mean, we have no way of forcing a carrier to provide a way to disable pushes in the app they provide; so to me the question is: do we want the user to be able to bypass the carrier's app standard behavior?

Comment 7

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

(In reply to Gabriele Svelto [:gsvelto] from comment #6)
> That would be the easy way but the story points to the fact that the user
> might want to disable WAP Push entirely - irrespective of what the carrier
> thinks. If that's the case then we need to add an appropriate option that
> blocks Gecko from delivering WAP Push messages and add the relevant switch
> in the Settings app.
> 
> I mean, we have no way of forcing a carrier to provide a way to disable
> pushes in the app they provide; so to me the question is: do we want the
> user to be able to bypass the carrier's app standard behavior?

User might want that, and that is not hard to implement in gecko.
I just think it can't work as expected, because anything we open to user is also open to carriers.

So carriers might just remove the switch in settings app.
We can't force them to keep it.

On the other hand, we can only block SI and SL even when receiving WAP Push is disabled, in case other messages, like CP or some carrier-specific type, are required for system operation.
So the "disable WAP Push" functionality will not act as what it's called. Even user disables Wap Push, they will still receive message from carrier through carrier-specific message.

Comment 8

[Gabriele Svelto [:gsvelto]]

(In reply to Chuck Lee [:chucklee] from comment #7)
> User might want that, and that is not hard to implement in gecko.
> I just think it can't work as expected, because anything we open to user is
> also open to carriers.
> 
> So carriers might just remove the switch in settings app.
> We can't force them to keep it.

Right.

> On the other hand, we can only block SI and SL even when receiving WAP Push
> is disabled, in case other messages, like CP or some carrier-specific type,
> are required for system operation.
> So the "disable WAP Push" functionality will not act as what it's called.
> Even user disables Wap Push, they will still receive message from carrier
> through carrier-specific message.

I see... OK, so this is basically in the carrier's hands and the only thing we need to implement is proper permissions regarding the API; in this case I think it's just a matter of making it accessible only from certified apps.

Comment 9

[Ken Chang[:kenkai]]

Hi Gabriele, do you have any concern to implement this function in Gaia? If not, I will assign this bug to you. Thanks.

Comment 10

[Ken Chang[:kenkai]]

Hi Gabriele, I have assigned to you. If you have any concern, let's keep discussing. thanks.

Comment 11

[Gabriele Svelto [:gsvelto]]

(In reply to Ken Chang from comment #10)
> Hi Gabriele, I have assigned to you. If you have any concern, let's keep
> discussing. thanks.

This is OK, I'm taking this bug into account while developing the application for bug 891762. Progress has been a bit slow on that because I was also working on some other bugs that turned out harder than I had anticipated.

Comment 12

[Gabriele Svelto [:gsvelto]]

Attachment: [PATCH] Support enabling/disabling WAP Push messages globally

This patch reads the "wap.push.enabled" settings key and reflects its changes by enabling/disabling WAP Push for all message types. This patch can be applied stand-alone or on top of the one for bug 887156.

Comment 13

[Gabriele Svelto [:gsvelto]]

Attachment: [PULL REQUEST] Support enabling/disabling WAP Push messages globally

Pointer to Github pull-request

Comment 14

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 798329 [details] [diff] [review]
[PATCH] Support enabling/disabling WAP Push messages globally

nit: add these keys to settings.js in build/

Comment 15

[Tim Guan-tin Chien [:timdream] (please needinfo)]

You should also move 

    window.navigator.mozSetMessageHandler('wappush-received',
      this.onWapPushReceived.bind(this));

In the callback of settings database so message will not get handled before you got the value from mozSetting. I think.

Comment 16

[Gabriele Svelto [:gsvelto]]

Attachment: [PATCH v2] Support enabling/disabling WAP Push messages globally

Updated patch with the issues in comment 15 addressed. The "wap.push.enabled" key was already added to settings.js in bug 896376.

Comment 17

[Gabriele Svelto [:gsvelto]]

... and merged.

master: b872bb9a5432ab297cf53c69874aef35df272b39

Comment 19

[Enpei]

Verified on 
Gaia:     aa4180e9286d385fa6b62d236f30fb24cd8b93e9
Gecko:    http://hg.mozilla.org/mozilla-central/rev/218d4334d29e
BuildID   20130909114657
Version   26.0a1