Closed Bug 1066385 Opened 10 years ago Closed 10 years ago

[System][Notifications] Add gaia support for behavior dict

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
2.1 S5 (26sep)

People

(Reporter: robertbindar, Assigned: robertbindar)

References

Details

Attachments

(1 file)

46 bytes, text/x-github-pull-request
aus
: review+
jrburke
: review+
mikehenrty
: review+
Details | Review
We need to add support in Gaia in order for apps to use the "behavior" dict.
Depends on: 912645
Attached file gaia_modes_dict
I think we need to land these changes all at once because otherwise we would have to firstly merge the SystemApp changes and disable the failing tests and then merge the apps updates and enable the tests again. If you're not ok with it let me know, I'll file some other bugs for that.
Attachment #8488372 - Flags: review?(mhenretty)
Attachment #8488372 - Flags: review?(jrburke)
Attachment #8488372 - Flags: review?(aus)
Comment on attachment 8488372 [details] [review] gaia_modes_dict The email change looks fine to me. After this lands, I will likely open a ticket that is email-specific to have our ux folks go over all the email notification scenarios to see if they want to adjust any of the behaviors, but this seems great as a baseline. Thank you!
Attachment #8488372 - Flags: review?(jrburke) → review+
Thanks James, there are more to come! About the behavior you guys discussed on Bug 1042361, it is more likely a B2G bug, from the spec perspective that's how the default behavior should be when replacing, no disrupting, we just need to edit it to be more clear on this matter.
Comment on attachment 8488372 [details] [review] gaia_modes_dict Looking good Robert! Ok, next thing we need is integration tests. Let's have a new integration test file in the system app. We need at least two tests for each new behavior: true and false for the boolean ones, and pattern and no patter for the vibration one.
Attachment #8488372 - Flags: review?(mhenretty)
Comment on attachment 8488372 [details] [review] gaia_modes_dict lgtm. minor nit for code style in github.
Attachment #8488372 - Flags: review?(aus) → review+
Attachment #8488372 - Flags: review?(mhenretty)
I fixed the nits and added a couple of integration tests.
Blocks: 1069981
I think this is a great opportunity to get rid of the noNotify/SILENT_APPLICATIONS/isResending logic. But that could be done in another patch I guess (involves changing call sites). With the current patch, applications can't say "don't vibrate nor ring". It should be possible to pass empty options. (In reply to Michael Henretty [:mhenretty] from comment #4) > We need at least two tests for each new > behavior: true and false for the boolean ones, and pattern and no patter for > the vibration one. I'd suggest three :) No pattern, empty pattern, pattern for vibration. No sound, empty sound, sound for sounds.
Blocks: 1073020
(In reply to Anthony Ricaud (:rik) from comment #7) > I think this is a great opportunity to get rid of the > noNotify/SILENT_APPLICATIONS/isResending logic. But that could be done in > another patch I guess (involves changing call sites). > > With the current patch, applications can't say "don't vibrate nor ring". It > should be possible to pass empty options. This is intentional. We did it this way because there were concerns in the whatwg mailing list that if we allowed users to disable vibration through this API, they might get a completely silent notification without meaning to. So for example, a user might want to disable vibration but play a sound. If the phone volume was turned all the way down they would get a silent notification without meaning to. To be clear, we fought for the ability to disable vibration, be we ultimately lost that battle for now. See this thread for more info: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-August/297575.html
Comment on attachment 8488372 [details] [review] gaia_modes_dict Great job Robert! I left a couple of comments on github about the tests, but other than that I think we are good to go! There are, however, a couple of weird issues with notification sounds, but I think we can fix these incrementally in follow ups: - First, we don't wait for the soundFile to load before displaying the notification. This can be weird UX when loading a large sound file from the network (ie. the toaster displays, and then a moment later the sound is played). - When a sound is longer than two seconds, we cut it off abruptly. It sounds like a record skipping. I think having the cutoff is a good idea, but the sound should fade out. - If a sound file doesn't load for some reason, we fail silently. Would be nice to have some sort of log explaining what happened. Please file follow-ups for these :)
Attachment #8488372 - Flags: review?(mhenretty) → review+
(In reply to Michael Henretty [:mhenretty] from comment #8) > (In reply to Anthony Ricaud (:rik) from comment #7) > > I think this is a great opportunity to get rid of the > > noNotify/SILENT_APPLICATIONS/isResending logic. But that could be done in > > another patch I guess (involves changing call sites). > > > > With the current patch, applications can't say "don't vibrate nor ring". It > > should be possible to pass empty options. > > This is intentional. We did it this way because there were concerns in the > whatwg mailing list that if we allowed users to disable vibration through > this API, they might get a completely silent notification without meaning > to. So for example, a user might want to disable vibration but play a sound. > If the phone volume was turned all the way down they would get a silent > notification without meaning to. To be clear, we fought for the ability to > disable vibration, be we ultimately lost that battle for now. > > See this thread for more info: > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-August/297575.html Fair enough. We can't let applications opt out of one of them but can we let them opt out of vibration and sound at the same time? This is the use case we want for bug 1069981 and bug 1073020.
(In reply to Anthony Ricaud (:rik) from comment #10) > Fair enough. We can't let applications opt out of one of them but can we let > them opt out of vibration and sound at the same time? This is the use case > we want for bug 1069981 and bug 1073020. Good idea. I just spoke to Jonas about this, and filed bug 1073717 to add the "silent" behavior.
I fixed the nits, waiting for the try run. Michael can you please
Blocks: 1073875
Blocks: 1073878, 1073876
Sorry, commenting failure :). I'll checkin-needed this when the try run is done.
Keywords: checkin-needed
Status: NEW → RESOLVED
Closed: 10 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → 2.1 S5 (26sep)
Blocks: 1049479
No longer blocks: 1073020
No longer blocks: 1049479
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: