937262 - alerts.totalOpenTime and Alerts.disableSlidingEffect has not effect when displaying alert from extension

Status: RESOLVED WORKSFORME

(Firefox :: Untriaged, defect)

Description

[Don Kleppinger]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release)
Build ID: 20130910160258

Steps to reproduce:

I have an extension that displays an Alert.  I have it set to slide up and display for 10 seconds.   This was working in 10.0.11esr but I just upgraded to 24.1.0esr and the alert is only displaying for about 3 seconds and not sliding.

I have thee values set
alerts.totalOpenTime=10000
alerts.disableSlidingEffect=false



Actual results:

Not sliding, not staying open for configured time.


Expected results:

Alert on windows task bar should slide up and display for configured time

Comment 1

[Don Kleppinger]

Code example

alertsService = Components.classes["@mozilla.org/alerts-service;1"]
                       .getService(Components.interfaces.nsIAlertsService);


alertsService.showAlertNotification(image, 
                                    title, text, 
                                    true, "alertcookie", alertListener,"eagleAlert");

Comment 2

[Mike Kaply [:mkaply]]

Unfortunately, since these were not officially supported prefs, there's not much we can do here.

totalOpenTime isn't used at all anymore.

disableSlidingEffect should still work.

Comment 3

[Don Kleppinger]

Thanks for the reply.
So there's no way to make my alert display for more than 3 seconds?  It's hardly long enough to notice it, read it and decide if you want to click on it to open a link   It also used to slide up slowly but now it just pops up and is gone within 3 seconds.  If the API is provided why would I not want to control how long it is displayed.  I guess I could keep it open by setting a timer and calling showAlertNotification several times in 3 second intervals but such a hack shouldn't be necessary.


https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIAlertsService

Comment 4

[Mike Kaply [:mkaply]]

You could switch to using HTML 5 Notifications which you should have a little more control over.

The problem here is that internally they switched to HTML 5 Notifications which aren't as full featured.

Comment 5

[Don Kleppinger]

I experimented with html 5 notifications on this page
https://developer.mozilla.org/en-US/docs/WebAPI/Using_Web_Notifications

But still has the problem of closing after 3 seconds.   This seems like a bug to me and the page even states the following

Note: Firefox and Safari do not follow the specification regarding the close event. The specification stated that a notification must be closed by the user only. However, Firefox and Safari close the notifications automatically after a few moments; therefore, there is no guarantee that it's the user who closed the notification.

The specification clearly stated that notification auto close should be done at the application level using the Notification.close() method, for example with the following code:

Comment 6

[opera wang]

MozillaZine has pages for this preferences @ http://kb.mozillazine.org/Alerts.totalOpenTime, which was removed in bug 786125 and use hard coded 4s in both alert.js and alert.css.

bug 782211 make all nsIAlertsService use alert.xul.

So the better fix might be either:
1. alert.js use the preferences
2. nsIAlertsService / alert.js accept one more argument to specify how long the popup window will show.

bug 703547 is similar to this one.

Comment 7

[Don Kleppinger]

Thanks for the info.  Since I'm building a customized version of firefox I was able to fix this by changing the value in alert.js and alert.css.   Still doesn't slide up but at least it displays longer now.

Comment 8

[opera wang]

In my addon, I do hacks to just set the animationDuration of alertBox to a longer timer in onLoad of the alert window. 
https://github.com/wangvisual/autoarchive/blob/master/src/content/log.jsm

But I still like to have a API that gecko can provide officially.

Comment 9

[Don Kleppinger]

Keeping the change in the addon is even better.  Thanks for the sample

Comment 10

[Justin [:JW_SoftvisionQA]]

I will close this bug per Comment 7.