57306 - Yank timebomb.* prefs, nsTimeBomb

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect, P1)

Description

[John Unruh]

1.) With a clean system, install the Win98 101908 branch build.
2.) Start the browser, close it and view the prefs.js file.
What I see: A timebomb pref.

Comment 1

[David Krause]

See also bug 44563: Optimization: Disable timebomb code for Mozilla

Comment 2

[Doron Rosenberg (IBM)]

granrose says "timebombs are already disabled in the ns build, we're not
removing the timebomb code from the ns build."

I think this belongs in bugscape anyways, as this is nsonly.

Comment 3

[Asa Dotzler [:asa]]

over to buildconfig

Comment 4

[Jon Granrose]

this isn't a build config bug, we don't hack the product, we hack the build
system.  removing timebomb code, even if we wanted to do that, would be some
browser hacker's job.  I'm punting to XP: Miscellany as a guess.

Comment 5

[Chris Waterson]

magic 8-ball says XPApps. Probably mcafee...

Comment 6

[Chris McAfee]

Not sure who owns this, adding ssu, dveditiz.

Comment 7

[Chris McAfee]

rtm

Comment 8

[don]

Do we still even read the timebomb pref?

Comment 9

[Chris McAfee]

this bug is for removing timebomb pref from prefs.js for rtm.
junruh just tested ns6 4 years in the future, it runs fine.
So, looks like we just have an ugly, unused pref for rtm.

Comment 10

[Blake Ross]

...so if having this pref in has no other consequence, why do we need to remove 
it for rtm?

Comment 11

[don]

Good question, Blake.  I say we minus this.

Comment 12

[sairuh (rarely reading bugmail)]

yeah, what i see is user_pref("timebomb.first_launch_time", "971306662751430");
in my prefs.js. obsolete pref? should prolly be a part of the fix [hah] for bug
33115.

adding relnote-devel, so that powerusers will know that they should pay no
attention to this pref [afaik]... "pay no attention to that line in the file..."
erm ;)

Comment 13

[sairuh (rarely reading bugmail)]

d'oh. double-collision. removing rtm need info.

Comment 14

[timeless]

restoring don's rtm-. It's silly but it's his.

Comment 15

[Viswanath Ramachandran]

Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
thanks,
	Vishy

Comment 16

[Paul Chen]

nav triage team:

It's not like we don't have other waste in the product. nsbeta1-

Comment 17

[Chris McAfee]

This pref is used in xpfe/components/timebomb/nsTimeBomb.cpp,
there is a whole nsTimeBomb class here.  Is the class not used?
Is this particular pref not used?  Please clarify.

Comment 18

[Paul Chen]

Marking nsbeta1- bugs as future to get off the radar.

Comment 19

[Gervase Markham [:gerv]]

Blake: is this being dealt with as part of your major prefs cleanup?

Gerv

Comment 20

[Gervase Markham [:gerv]]

Right. The actual bug here is that we are initialising an instance of 
nsITimeBomb, which is writing a pref:
user_pref("timebomb.first_launch_time", "986046281420000");
to prefs.js. That's the one people are seeing, and that is confusing them.

There are two solutions. 
a) get nsTimeBomb.cpp to only write this pref if the pref timebomb.enabled is 
set.
b) Work out why and where we are creating an instance of nsITimeBomb in the 
first place, and stop it.

b) reduces bloat (does it?). a) makes the life of someone who wants to use the 
timebomb easier.

If anyone wants to do a patch for a), they just need to add a check that that 
pref is set to the if() statement at:
http://lxr.mozilla.org/seamonkey/source/xpfe/components/timebomb/nsTimeBomb.cpp#
99

I would do it, but I'd have to reboot, work out the right syntax for getting 
prefs, do a build (2 hours), etc. etc. Blake? ;-)

Gerv

Comment 21

[Hixie (not reading bugmail)]

Wow, we're still building the time bomb code? I say we remove this from the
build altogether. It would shave a good millisecond from our startup time and
a good kilobyte or so from our download time... every little bit counts, and
this should be _easy_. :-)

Comment 22

[Gervase Markham [:gerv]]

Yeah, OK hixie :-) It's just that this pref worries people - I have actually 
seen it on the newsgroups; people are afraid their Netscape 6 or Mozilla 0.8 are 
going to blow up at some point.

Gerv

Comment 23

[Hixie (not reading bugmail)]

Unbelievably, I actually *wasn't* being sarcastic...

Comment 24

[[e-mail]]

Re b), nsTimeBomb is referenced from nsModule.cpp (lines 47 and 84) to
initialize its static components[] array, so you could try disabling those lines.

Comment 25

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

so, what do we wanna do here? Just remove from build or do we wanna remove the 
actual files aswell? I'd vote for removing the files since the code is most 
likely bitrot anyway

Comment 26

[Chris McAfee]

timebomb code is beta-only, for rtm we need to:
  1) Not write out any timebomb.* prefs out to prefs.js
  2) Possibly yank the nsTimeBomb class, since we won't be
     using it.

Comment 27

[Chris McAfee]

vishy

Comment 28

[Blake Ross]

--> me

Comment 29

[Blake Ross]

Attachment: remove timebomb

Comment 30

[Blake Ross]

I can't tell from this bug what the consensus is. Are we removing nsTimeBomb
altogether, or what? I'd say yes since it's causing us to do unnecessary work,
and I don't think we turned on timebombs for at least the last PR, and possibly
more.  Otherwise we can just set timebombChecked to PR_TRUE if people think this
is still being used.

Comment 31

[Chris McAfee]

I believe nsTimeBomb needs to go.  Removing rtm from summary since that
is adding confusion.  granrose, please correct me here if needed.

Comment 32

[Blake Ross]

mcafee, review?

Comment 33

[Chris McAfee]

this patch also adds downloadmgr, is that intended?
r=mcafee for everything else.  Did you get unix Makefile.in's also?  Mac?

Comment 34

[Blake Ross]

Fixed.

Comment 35

[timeless]

*** Bug 44563 has been marked as a duplicate of this bug. ***

Comment 36

[Peter Trudelle]

My understanding is that we still need timebomb for beta releases.  What is the
plan for enabling it if now that it isn't there?

Comment 37

[Chris McAfee]

timebomb code, says granrose, is not used to do the timebomb mechanism
and is an external mechanism.

Comment 38

[sairuh (rarely reading bugmail)]

vrfy fixed by checking lxr.