timebomb not working

VERIFIED FIXED in mozilla0.9.9

Status

P1
blocker
VERIFIED FIXED
17 years ago
13 years ago

People

(Reporter: granrosebugs, Assigned: bugzilla)

Tracking

Trunk
mozilla0.9.9
x86
Windows NT

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
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

17 years ago
 someone one the apps team should own this.

Assignee: dougt → asa

Comment 2

17 years ago
->morse  p1/098
Assignee: asa → morse
Priority: -- → P1
Target Milestone: --- → mozilla0.9.8

Updated

17 years ago
QA Contact: doronr → ktrina
(Reporter)

Comment 4

17 years ago
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?

Comment 6

17 years ago
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.
(Assignee)

Comment 7

17 years ago
From that bug:

------- Additional Comment #37 From mcafee@netscape.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?

Comment 8

17 years ago
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?
(Reporter)

Comment 9

17 years ago
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

17 years ago
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

17 years ago
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.
(Assignee)

Comment 12

17 years ago
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

17 years ago
Reassigning to blake at his request
Assignee: morse → blaker

Comment 14

17 years ago
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
(Assignee)

Comment 15

17 years ago
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
(Assignee)

Comment 16

17 years ago
Created attachment 65794 [details] [diff] [review]
patch

Comment 17

17 years ago
looks like  this is ready - anyone up for reviewing this?
Keywords: review
(Assignee)

Updated

17 years ago
Keywords: nsbeta1
(Assignee)

Comment 18

17 years ago
okay - fixed. (r=hewitt/sr=ben)
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 19

17 years ago
Verified code fix
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.