If I enable the timebomb in all-ns.js (Netscape build) in the 2001111903 trunk win32 build on win98 and win2k: pref("timebomb.enabled", true); with the timebomb date set to the default 11/15/00, I do not get a timebomb dialog box popping up when I start the browser. I'm assuming this is true for mozilla builds as well, but this bug can get moved to bugscape if that is not the case. I've reproduced this problem on today's trunk build as well.
someone one the apps team should own this.
Assignee: dougt → asa
Assignee: asa → morse
Priority: -- → P1
Target Milestone: --- → mozilla0.9.8
Also see bugscape http://bugscape.netscape.com/show_bug.cgi?id=10957
10957 shouldn't be a problem once http://bugscape.netscape.com/show_bug.cgi?id=11138 is fixed.
How's bug 57306 ("Yank timebomb.* prefs, nsTimeBomb", FIXED) related to this?
OK, I'm confused. It looks like all the timebomb code was intentionally ripped from the product in bug 57306. So of course enabling the timebomb pref will not cause you to get a timebomb popup. Is there a point that I'm missing? Someone please give me a good reason why I shouldn't close this bug out as invalid.
From that bug: ------- Additional Comment #37 From email@example.com 2001-10-24 10:22 ------- timebomb code, says granrose, is not used to do the timebomb mechanism and is an external mechanism. --- And I confirmed that before checking in. I was told that what was being removed was old cruft. Perhaps a bit too much was removed?
I'm still confused. Are you saying that this bug is invalid? Or are you saying that this bug involves restoring part of the code that was ripped out for bug 57306?
regardless of what happened in 57306, Netscape needs the timebomb to work. If that can happen in mozilla, great. If not, this will have to be moved to bugscape and fixed in the ns tree, so this bug should never get resolved as invalid. Originally, 57306 was just to keep the timebomb prefs from showing up in the prefs file unless the timebomb was on. It appears that somehow it got morphed into "yank out all the timebomb code". Mozilla doesn't do timebombs, so I can see why they wouldn't want it in their tree. Netscape does do timebombs for all non-final releases, so we need it. I'm not a developer, but I think the best solution would be to put the timebomb code back in place in the mozilla tree, but fix it so that there is no pref in the prefs file unless the timebomb is enabled.
this is a bugscape bug, I suggest we move it over and retitle this bug to avoid further confusion. Thanks for granrose clearing this up.
Are you sure it is a bugscape bug? I like what granrose said about keeping it in the mozilla codebase (but making sure it's not in the pref file if not used). If you are concerned about code bloat, it can be under control of an #ifdef. That way anybody wanting to modify the mozilla code for his own use with a timebomb doesn't have to go reinventing everything.
Okay, so there was some miscommunication here. I doublechecked that the timebomb code in Mozilla was not the same as that used for Netscape builds (see comment 37 in that bug), but Jon thought I meant the prefs. So I say we just revert the changes. Morse, do you want me to do that?
Reassigning to blake at his request
Assignee: morse → blaker
Marking blocker severity, as this blocks Andreww from fixing Bugscape bug 11138. Blake, will you be able to fix this today (as TM implies)? If not, when do you think you will?
Severity: normal → blocker
I could fix it now but I don't think I'll get reviews tonight anyway, so I will fix it tomorrow when I get home.
Target Milestone: mozilla0.9.8 → mozilla0.9.9
looks like this is ready - anyone up for reviewing this?
okay - fixed. (r=hewitt/sr=ben)
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Verified code fix
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.