Closed Bug 1042361 Opened 10 years ago Closed 9 years ago

[email] Avoid disruptive notification modes if a notification for the account already exists

Categories

(Firefox OS Graveyard :: Gaia::E-Mail, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: khuey, Unassigned)

References

Details

Attachments

(1 file)

If I have email set up to poll every five minutes, after I get one notification I should not get anymore until after I've cleared and read that one.
The UX/Product design for email notifications is to only ever show one notification per account. That notification is updated to reflect the current state over time though. So, if first sync only fetches one message, but then the next one fetches two, the notification should just show "3 messages" for the notification text.

This is complicated by bug 922722, which means the notification will just say "2 messages", the last sync amount (not the total count), but the end result is that there is just one notification per email account and it reflects the total number that have not been seen.

Is the issue that the notification sound is triggered with the notification is updated? If so, then perhaps we can roll in a fix for that as part of bug 912645.

So, is this bug more the disruptive notification behaviors with the notification updates, or do you prefer to see only the first notification state?
Flags: needinfo?(khuey)
(In reply to James Burke [:jrburke] from comment #1)
> Is the issue that the notification sound is triggered with the notification
> is updated?

Yes.

> So, is this bug more the disruptive notification behaviors with the
> notification updates

Yes.
Flags: needinfo?(khuey)
Let's use this bug to track a change in email to use a mode for notifications, once bug 912645 is available, to indicate "do not disturb the user if notification already exists, just update the notification contents". And I will comment in that other bug about wanting a mode like this.
Depends on: 912645
Summary: Unread email notifications should not fire repeatedly → [email] Avoid disruptive notification modes if a notification for the account already exists
Some notes on this: there is mozbehavior now to specify some behaviors, but for sound, the only option is soundFile with a URL to a sound file. It sounds like the standardization process will be changing the names of the mozbehaviors, and "silent" will be an option in those standardized names, so we should switch to that when available. Some background:

https://github.com/whatwg/notifications/issues/22
https://notifications.spec.whatwg.org/

What we could do in the meantime is to provide a "silent" sound file, I will experiment with doing that.
Attached file GitHub pull request
Uses a soundFile that is just silent and a vibrationPattern of [1] for subsequent updates to new email notifications, since "silent" option not available in current supported mozbehaviors.

Asking :mhenretty for feedback, particularly the vibrationPattern part. Kind of a hack, but seems to work.

The half-second silent sound was created like so:

sox -n -r 48000 -b 16 -c 1 silent.wav trim 0.0 0.5
opusenc silent.wav silent.opus
Flags: needinfo?(mhenretty)
Attachment #8538896 - Flags: review?(bugmail)
Comment on attachment 8538896 [details] [review]
GitHub pull request

Que sera, sera.  (I don't type accents, but imagine them there.)

I sign off on this on the understanding that this may result in music being eclipsed by a half-second sound of silence, which is in and of itself, a form of notification.  (Actually, on Android, this is exactly what happens when I get text messages and I'm listening to music through my headphones.  The sound just dips to nothing for a second and then back again.  I'm unclear if it's the phone's way of avoiding deafening me with a loud beep directly into my ears or what.)

I do suggest we wait for :henretty's response in order to shift the guilt over this to him! ;)
Attachment #8538896 - Flags: review?(bugmail) → review+
Comment on attachment 8538896 [details] [review]
GitHub pull request

I'm sorry you have to do workarounds like this because notifications hasn't been implemented to spec yet.

The vibration for 1ms effectually works fine, as well as playing a silent sound. While we are at it, you could also specify a fake url (ie. soundFile: "nosound" or something), but doing the "silent.opus" sound will indeed turn down any background music for sound's duration. I'm not sure if this is what you want here, since the forthcoming completely silent notifications will not have this behavior. But I'll leave it up to you.
Flags: needinfo?(mhenretty)
Comment on attachment 8538896 [details] [review]
GitHub pull request

Asking for a review again since I changed the approach to use a non-existent URL instead of an empty sound file, as suggested in comment 7.

I originally did not want to do that as I do not like passing malformed data, but can appreciate that we want to simulate what will really happen with the final standard option, so did the change. Details on the diff since last reviewed state are in githubm comment:

https://github.com/mozilla-b2g/gaia/pull/26897#issuecomment-68957415
Attachment #8538896 - Flags: review+ → review?(bugmail)
Attachment #8538896 - Flags: review?(bugmail) → review+
Merged in master:
https://github.com/mozilla-b2g/gaia/commit/7d5288bfb81026ead04c09a461b132a798eec318

from pull request:
https://github.com/mozilla-b2g/gaia/pull/26897
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: