112071 - timebomb not working

Status: VERIFIED FIXED

(SeaMonkey :: General, defect, P1)

Description

[Jon Granrose]

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.

Comment 1

[Doug Turner (:dougt)]

 someone one the apps team should own this.

Comment 2

[Peter Trudelle]

->morse  p1/098

Comment 3

[lchiang]

Also see bugscape http://bugscape.netscape.com/show_bug.cgi?id=10957

Comment 4

[Jon Granrose]

10957 shouldn't be a problem once
http://bugscape.netscape.com/show_bug.cgi?id=11138 is fixed.

Comment 5

[Boris Zbarsky [:bzbarsky]]

How's bug 57306 ("Yank timebomb.* prefs, nsTimeBomb", FIXED) related to this?

Comment 6

[Stephen P. Morse]

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.

Comment 7

[Blake Ross]

From that bug:

------- Additional Comment #37 From [e-mail] 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?

Comment 8

[Stephen P. Morse]

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?

Comment 9

[Jon Granrose]

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.

Comment 10

[Chris McAfee]

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.

Comment 11

[Stephen P. Morse]

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.

Comment 12

[Blake Ross]

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?

Comment 13

[Stephen P. Morse]

Reassigning to blake at his request

Comment 14

[Peter Trudelle]

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?

Comment 15

[Blake Ross]

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.

Comment 16

[Blake Ross]

Attachment: patch

Comment 17

[andreww]

looks like  this is ready - anyone up for reviewing this?

Comment 18

[Blake Ross]

okay - fixed. (r=hewitt/sr=ben)

Comment 19

[K'Trina Medina]

Verified code fix