BUILD: "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081112 Minefield/3.1b2pre" but I was seeing this with a 2008-11-11 build too. STEPS TO INTRODUCE: 1) Install the build 2) Start the browser and wait for a day, so that the update will get downloaded 3) Get an application update prompt that asks whether you want to restart now or later 4) Select "Later" EXPECTED RESULTS: No more prompting for a while (not sure how long, but at least a few hours). ACTUAL RESULTS: Prompt comes up again 10 minutes later (timed it twice in a row now). Pretty sure this didn't use to happen....

This was caused by bug 324121 and I suspect this is due to your platform not supporting the alert service. bz, can you confirm the second part of the previous statement? The timer code is a mess and I am planning on fixing it and this bug in bug 462568

Um.. how would I confirm the second part? I'm just running our trunk nightly on Intel OSX 10.5, like the build id says. There certainly seems to be an nsAlertsService.mm; no idea whether it's built or anything.

Thanks, that confirms that you do have the alert service. It is most likely due to the mess that the timer code is in.

Hey, Robert. I'm setting a P2 priority here. This is a pretty pesky bug.

No worries... it is a no brainer to change it to the previous behavior but I hope to make it so it works properly (bug 462568)

I'm going to backout the change that caused this and try to come up with a better fix in bug 462568.

Pushed to mozilla-central http://hg.mozilla.org/mozilla-central/rev/d7b41102de3b

Pushed to mozilla-1.9.1 http://hg.mozilla.org/releases/mozilla-1.9.1/rev/189ec8c581e5

Verified fix on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090213 Shiretoko/3.1b3pre Ubiquity/0.1.5 and Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090212 Minefield/3.2a1pre had both these browsers sit overnight in the "Later" mode