Closed Bug 875114 Opened 11 years ago Closed 9 years ago

Web notifications should optionally be permanent, not automatically close after 4 seconds

Categories

(Core :: DOM: Core & HTML, enhancement)

Product:
Core
Component:
DOM: Core & HTML
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 862395

People

(Reporter: cdarsch, Unassigned)

References

Details

(Keywords: uiwanted) 

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31

Steps to reproduce:

Ran a web app that posted a desktop notification.


Actual results:

The notification disappeared automatically after 2 seconds. This is the same behavior that the HTML Desktop Notifications add-on used to have; the add-on has now been fixed so that the notifications stay up.


Expected results:

The notification should remain visible until it is closed by the user or the web app. This particular web app (in development) depends on the notification remaining visible so that the user can refer to it while working in another window.
Right now the desktop notifications are meant to last few seconds, as you can see here: https://bugzilla.mozilla.org/show_bug.cgi?id=782211#c118.

I'm changing the priority to enhancement for now; if this change is already planned on the bug that I referenced or somewhere else this bug might be also marked as duplicate.
Thank you for your report!
Severity: normal → enhancement
Component: Untriaged → DOM
Product: Firefox → Core
See Also: → 782211
Blocks: 782211
See Also: 782211 → 
Sometimes notifications disappear before I get to read them and this is probably because I have a large display and my eyes are normally on the opposite side of the screen.

Whether websites should be able to prevent the auto-close behaviour is being handled in bug 862395. This bug can handle what the default behaviour should be.
OS: Windows 7 → All
Hardware: x86_64 → All
See Also: → 862395
Summary: Desktop notifications should not timeout after 2 seconds → Web notifications should not timeout after 4 seconds by default
Is there a way to patch Firefox 24? I'm using ESR because I can't afford to mess around with a hundred tabs every 42 days and this bug negates the point of having web notifications since they completely disappear on their own!
(In reply to John A. Bilicki III from comment #3)
> Is there a way to patch Firefox 24?

This bug is not yet fixed even on trunk.

> I'm using ESR because I can't afford to
> mess around with a hundred tabs every 42 days

A security update will be offered for every six weeks anyway. Also, Firefox added a session restore feature far back.
I was so glad when Firefox announced support for Web Notifications (as I wished to use it as my browser of choice for Google Apps) but currently the HTML5 spec has been implemented improperly by Firefox imho as it does not mention a default timeout and this means that notifications from apps such as Google Calendar are easily missed if they are triggered when the user is away from the device or whilst looking away from the screen for a few moments.

It should be up to the website to close the notifications when it chooses.  Forcing them closed after a short period of time doesn't really make sense, especially not when the user has to explicitly grant the website permission to show them in the first place (and can easily revoke this permission.)

Thanks for reading.
PS: The W3C spec can be found here: http://www.w3.org/TR/notifications/
Andre from pushbullet here. Our service is centered around sending notifications to yourself and your friends. It would be really really nice to get this implemented as our users complain daily about the 4s timeout. It would be really really nice we can set the duration (to the users specification) like we can in Chrome.

Thanks!
Come on, Mozilla!  This seems like it would be such a small change and yet would make a massive difference to many.  Can anyone take this bug?  Cheers.
(In reply to treeform from comment #7)
> It would be really really nice we can set the duration (to the users
> specification) like we can in Chrome.
> 
> Thanks!
Who's idea was to implement notifications with hard coded 4 sec auto close, without feature to stay on until user close it? Urghhh -.-
Isn't this something rather done per-product than Core:DOM?

Thunderbird's new mail alert feature can perhaps provide some insight how to do this as a global setting and/or implement a per-site setting in a doorhanger (may depend on Bug 852658).
Flags: needinfo?
Keywords: uiwanted, ux-control
Version: 24 Branch → Trunk
There's no chance this will be in 29, 30 or in the foreseeable future for various reasons - including a draft how to handle the timeout (global vs./and site-specific) and how to put this UI wise.

and yes, "me toos" and explaining usecases do not accelerate the process - as always.
I think notifications staying forever by default is bad UI. Desktop notifications are very intrusive. Intrusion should be minimized and thus they should be transient. If a user has to manually act for every notification, that can annoy very quickly.

There may be valid usecases for notifications to be permanent (although I can't see any right now), so I guess there's a case for a parameter to make them permanent, but the vast majority should be transient.

And yes, even Android annoys me that every PDF click stays for weeks until I manually close it.
Keywords: ux-control
I removed keyword "ux-control", because a user that gets popups (or notifications), which he then has to close manually, does not feel in control. If the UI does something that the user didn't initiate, and the user has to clean up, the user isn't in control, but the computer makes the user work, in a very literal way. Bad UI.
> I guess there's a case for a parameter to make them permanent

Actually, that could be user-controlled as well. E.g. in the same dialog that grants the permission to show the notification at all, the user can also choose whether they auto close or not. And then in the notification itself, there could be a prefs button (like in GChrome) to change it later.
Summary: Web notifications should not timeout after 4 seconds by default → Web notifications should optionally be permanent, not automatically close after 4 seconds
BenB - I agree that some users might want notifications to be forcibly closed after a certain period of time but bear in mind that:

a) Before seeing any notifications at all, the user must explicitly give each site permission to display them & can easily revoke this
b) W3C specs are normally well thought out and should be adhered to when possible imho
c) I can think of many apps that would have very legitimate reasons for wanting to create a notification that remains until dismissed by the user.  For example, the Google Calendar example given earlier, some web-based chat client, an app that monitors your servers and notifies you when they are down, etc.  Basically any app wanting to show notifications that the user would not want to miss if they were AFK / looking away from screen for a moment.

Cheers, Ben K
> b) W3C specs are normally well thought out and should be adhered to when possible imho

The spec doesn't state that it must stay open. It leaves this issue entirely unspecified.
The spec does state that the browser can chose to close notifications at will. Quote:
| When a notification is closed, either by the underlying notifications platform or by the user, the close steps for it must be run.
> a) Before seeing any notifications at all, the user must explicitly give
> each site permission to display them & can easily revoke this
This is not true, as the (hardcoded) four-second timeout applies to any site or add-on using the nsIAlertsService interface (directly or indirectly via HTML5 Notifications).
const ALERT_DURATION_IMMEDIATE = 4000;
BenB: that's a good point tbh and I accept it.  I think we both agree then the best thing to do would be to allow the user to specify a maximum duration (including the possibility of "no maximum")

rctgamer3: I meant HTML5 Notifications specifically as that is what is under discussion.  If Firefox chooses to use an existing interface in order to implement Web Notifications, I think that existing interface should be extended to support a _user_configurable_ notification duration value (e.g. an unsigned integer number of seconds where 0 = infinite) that can be applied to HTML5 Notifications independently.
What's well thought are the Windows 7 notifications. They slowly vanish during 6-7 seconds (by becoming transparent), but only after the user makes any input, eg a mouse move. He/she can make it stop vanishing and fully visible again by putting the cursor above it.

The current solution is bad. If I'm not in front of my computer and I'm not lucky enough that it is already in the idle state, I miss the notification. If I want to read it, it harshly disappears without any hint, as no linear vanishing is involved (no call for action).

Also it would be great if you could make automatically any magic number accessible from about:config. Then I could at least partially fix this.
> What's well thought are the Windows 7 notifications. They slowly vanish during 6-7 seconds
> (by becoming transparent), but only after the user makes any input, eg a mouse move.
> He/she can make it stop vanishing and fully visible again by putting the cursor above it.

+1
That would be a better solution. Can you file a new bug with your suggestion?
Problem in Firefox is that the notifications are not collected. Just only display and disappear after some seconds.

I test this API in Chrome 34 on Win7 and we have special icon in tray menu, where we can manage all notifications. If we don't close notifications (only active) this notifications goes to manager. At one time we see max 3 notifications (continuously displayed until we close), others are queued and appear when close previous. This solution is really comfortable and seems to be more consistent with the specification. 

And in Firefox, when we activate notification (by click on them) we generate click event and close event. In Chrome only click event, this notification goes to manager (where still can be activated or closed << firing corresponding event).

Automatic closing notification generate close event and we don't know if user realy read this info and no longer need them. Something like works in Chrome would be great, but I don't know whether it is possible in Firefox.
The HTML5 Notifications API uses the Mozilla nsIAlertsService interface[1]. The chrome URL for alerts is [2] which leads to [3]. Within [3], on line 72 is "const ALERT_DURATION_IMMEDIATE = 4000;". It's not as simple as changing that constant since other alerts use the same constant.

I'm not well versed with this codebase, but hopefully this provides somewhat of a starting point for someone who is.

[1]: https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIAlertsService
[2]: chrome://global/content/alerts/alert.xul
[3]: chrome://global/content/alerts/alert.js
Let me post my workaround here. I use this with an if(firefox) condition.

notification.onclose = function(){
	var d = new Date();
	if(d-notification.openedat>3990){
		// DISPLAY A NEW NOTIFICATION RECURSIVELY
	}
}

This temporary solution keeps displaying new notifications recursively as long as the user does not close it manually - as a result, the notification is "blinking" which is somehow advantageous as well. A bit ugly? Yes. A bit messy? Yes. But at least it works and you don't miss any notifications. 

With a little modification you can alter it to have a permanent timeout, too.

I focused on Firefox for PCs, mobile devices might not need multiple alerts on their statusbar.

I cross my fingers and hope that guys at Mozilla will fix this bug soon.
It's possible to fix it by editting file C:/Program Files (x86)/Aurora/omni.ja
this file is jar whith contains mentioned file alert.js in chrome/toolkit/content/global/alerts/alert.js

And you should comment part of code responsible for closing nottifications

  if (Services.prefs.getBoolPref("alerts.disableSlidingEffect")) {
    setTimeout(function() { window.close(); }, ALERT_DURATION_IMMEDIATE);
    return;
  }

  let alertBox = document.getElementById("alertBox");
  alertBox.addEventListener("animationend", function hideAlert(event) {
    if (event.animationName == "alert-animation") {
      alertBox.removeEventListener("animationend", hideAlert, false);
      window.close();
    }
  }, false);
  alertBox.setAttribute("animate", true);

  if (gAlertListener) {
    gAlertListener.observe(null, "alertshow", gAlertCookie);
  }

First condition closes notification when annimations are diabled in about:config after 4s and if not, nottification has set annimation time in alert.css in same directory in this property 
animation-duration: 4s; so you can change it if you want more time

But this is user way how to fix it, but i'm not sure, what update make with that change.
First-time poster here, please be lenient ;)

Looking at what Ben quoted from the spec and then judged:

> When a notification is closed, either by the underlying notifications platform _or_ by the user the close steps for it must be run.

It would seem to me that the latter part of the quote is ignored by the current implementation. Perhaps I'm not a good enough interpreter. Thoughts?
This bug was opened in May 2013 (about 1.5 years ago.)  Regardless of the W3C spec, it seems very clear to me and others that an option to disable the auto-closing of notifications would be useful.  

So, why the hold up?  I could understand if this was a monumental code change, but I can't see why this would involve anything more than wrapping the 'auto close notification' part up like this pseudo code:

if (config.autoCloseNotifications)
{
   // existing code that that closes notifications after 3-4 seconds
}

and then adding a checkbox to the Content panel on the Options window.

As I've said before, the fact that Firefox Desktop auto-closes notifications makes certain ones almost useless to me - I tend to be away from the computer quite often and would rather let the web site choose when to close the notification (using the Web Notifications API) than have Firefox heavy handedly close the notification after 3-4 seconds so that when I come back there is no sign that anything happened.

I really don't understand why such a simple bug has not been closed.  :-(
Based on a chat I had with Anne van Kesteren (https://twitter.com/annevk/status/523572380934090753), Firefox should follow the WHATWG specifications for this API. According to that, the Firefox implementation is incorrect as the relevant property, called sticky (https://notifications.spec.whatwg.org/#sticky-preference-flag), is false by default (so the notification is permanent). Besides, the Firefox implementation misses this property completely, thus it should be implemented.
Will this ever be fixed?
I would also like to have more control of these notifications. This thing needs someone to work full time to add a lot of stuff to the notifications. For example, I would like to have:

- time to auto-close with 3 options: 5 seconds, never and custom
- option to fade out
- option to disable the sound when the notification is triggered
- option to change the sound - 5 in-built sounds from Mozilla and Custom (to choose file from my PC in mp3,
  opus..)
- option (maybe by default?) to display the number of auto-closed notifications somewhere at the top of firefox (far top left maybe?) ....(not sure if possible, but displaying a little number in Windows taskbar next to Firefox icon would be really cool too)
(In reply to Ben Bucksch (:BenB) from comment #23)
> I think notifications staying forever by default is bad UI. Desktop
> notifications are very intrusive.

Ben, while that is your perception of desktop notifications, different users have different use cases. For example, I monitor new StackOverflow questions, and it's possible for a new question to show up while I'm busy answering the current one. I definitely do not want to miss the notification of the new question, and wouldn't perceive it as intrusive because *I made that StackOverflow notifications app* [http://dandascalescu.com/static/SEnotify.html].

> Intrusion should be minimized and thus
> they should be transient. If a user has to manually act for every
> notification, that can annoy very quickly.

The user should be trusted, and Firefox should not be a nanny browser. Please fix this.
The workaround for this bug I use is to install 2 add-ons:
1. https://addons.mozilla.org/en-US/firefox/addon/no-native-notifications/ to replace native notifications with XUL-based. 
2. https://addons.mozilla.org/en-US/firefox/addon/idontwanttomissanotification/ to set duration of that XUL-based notifications to a desired value.
Works for me in FF40.0.2 on Windows 7 x86.
Serge, the problem is that we Firefox users are becoming EXTREMELY dependent on extensions for NORMAL functionality while Mozilla keeps adding garbage icons like Hello, share, etc that I have to remove not just from my own copies but also for clients. I know you mean well trying to help but ultimately Mozilla needs to be pressured to do the right thing.
I think that we need to get the FF implementation in line with the spec: 

https://notifications.spec.whatwg.org/#sticky-preference-flag

From a user point of view, FF should have consistent behavior as WebPush comes in. Today on OsX by default the notifications disappear, similarly to Windows. The difference is that the user can change the behavior in Notification Center settings in OSX, but not in our non-native treatment of notifications in Windows. Due to the absence of a system tray there is literally no way to see these messages once they disappear. 

I think that the default behavior in OSX should be "Alerts" which are sticky, and we should for now change the notifications in Windows to be sticky as well at this early stage of Notifications development.
Flags: needinfo?(martin.thomson)
Bill, you are right that persisting would be ideal.  Note also that "Alerts" on OS X will allow us to add extra user controls.  However, prioritizing this is a call that the front end team will have to make.
Flags: needinfo?(martin.thomson)
Bug 862395 is giving the webpage a choice about this and this bug is confusingly talking both about user and author's choices. Since an extension can easily give the users choice once bug 862395 is implemented I doubt we will complicate the UI for users so duping for now.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
I just want to chime in that this is something I have been hoping for a long long time! :)

I always multi task, the notification shows on one of my monitors, and I miss it because I was looking at another, happens all the time :(

Very eager to see an a "gear" icon in the notifications that allow us to set this time to 4sec or permanent. In Firefox 44, I saw the gear icon, got so excited, but still 4 second fade out :(
I have worked out a temporary solution for now. Below is defaulted to show at max 5 notifications on the screen.It will re-create a newer instance once previous one gets disappeared. If a user performs any activity meanwhile, all created instances will exit gracefully.

var firefox_count_notification = 5;
var firefox_count = 1;
var last_activity = new Date();
// default close timeout is approx 5 secs
var default_ts = 5 * 1000;
var notify_me_firefox = function() {
    // it creates dummy notification in order to keep it alive
    var create_notification = function (auto_generated) {

        if (firefox_count > firefox_count_notification) {
            return;
        }
        // increment the counter
        firefox_count = firefox_count + 1;
        // // set last_activity
        var create_activity = new Date();
        if (auto_generated && ((create_activity - last_activity) < default_ts)) {
            // newly queued alerts should not go live if user has just performed
            // click/close action
            return;
        }

        var notification = new Notification('New Alert!', {
            // icon property seems not to be working with firefox.
            body: "Hi! New alert Notification.",
            requireInteraction: true,

        });

        notification.onclose = function() {
            // decrement the counter
            firefox_count = firefox_count - 1 ;
            // set last_activity
            new_activity = new Date();
            if (((new_activity - create_activity) < default_ts) || (((new_activity - last_activity) < default_ts))) {
                // there is no way user can click on cancel after screen disappeared.
                // Hence user has just clicked on the icon.
                // don;t create any new notification.
                // also set last_activity, so that other created instances should terminate
                last_activity = new_activity;
            } else {
                // create another notification
                setTimeout(function(){create_notification(true);}, 100);
            }
        }
    }
    // actual code starts from here
    if (!Notification) {
        alert('Desktop notifications not available in your browser. Try Chromium.');
        return;
    }
    if (firefox_count > firefox_count_notification) {
        return;
    }

    if (Notification.permission !== "granted") {
        Notification.requestPermission();
    }
    else {
        create_notification(false);
    }
};
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.