Should potentially be a better design so that its not rebuilt. Should consolidate release team related settings (user-agent, version number, timebomb etc.) into one script based solution and at least be XP.

holding with me for the prefs owner... for now!

we need a place to tack on build numbers. so there would potentially be 5.01-YYMMDDHH

re: leaf's mail, build number should be part of the regular build and not a release-thing.

Since this is a release engineering feature, we'd like to get an implementation done soon so we can debug it and have all the kinks worked out by the beginning of January, since QA is going to be kicking up then and we need a daily build number process in place for FullCirlce. Gagan tells me that this should take too long. (Of course, he doesn't own the bug either.) Can you give me an approximate ETA for when this will be done? If it's not until mid-January, I need to know so I can go lobby your boss to get the priority raised. Thanks.

Which bug is being referred to here? o better design for timebomb o need ability to tack on build numbers o timebomb not working for Mac & Unix Sarah mentioned someone had put in a hack to make 'it' work. Could one of you clarify what the hack was and what it was addressing. I wasn't sure what 'it' was referring too. Also, what are the details of the bug "timebomb not working"? Does the browser crash, ignore timebomb settings, need more timebomb criteria, or what?

Which bug is being referred to here? o better design for timebomb o need ability to tack on build numbers o timebomb not working for Mac & Unix Sarah mentioned someone had put in a hack to make 'it' work. Could one of you clarify what the hack was and what it was addressing. I wasn't sure what 'it' was referring too. Also, what are the details of the bug "timebomb not working"? Does the browser crash, ignore timebomb settings, need more timebomb criteria, or what?

Currently, there is a hack in mozilla/xpfe/xpviewer/src/nsViewerApp.cpp and nsBrowserMain.cpp, which requires modification to the source files before build time to set a time in the future when the app just stops working. There is no dialogue given to the user (unless there is some sort of console for stderr to print to). I don't know how this worked before, but i believe it was set in a preferences file before compilation. I don't know that this is the best way for it to be handled, though. Preferrably, an app with a timebomb ought to give some kind of gui dialogue at startup (depending on warning time) and also a window explaining that the timebomb has expired when the timebomb date has been exceeded.

Setting all current Open/Normal to M4.

not sure if this is still relevant, but changing product to Browser

not sure if this is still relevant, but changing product to Browser

I've debugged the netlib version of timebomb a little bit (which I assume is what people will be using) I've worked around problem where the timebomb preferences were being set/used before libpref was initialized. On viewer.exe, I now see the FE_Alert showing up on the console (msdos window) for win32. On apprunner.exe I don't see the FE_Alert because it is being mapped into nsWebShell::Alert and mNetSupport observer hasn't been initialized. At this point, I'd appreciate some help looking at this. The pref problem is known and I have a fix for it, but the pieces of code that use the timebomb preferences still need debugging.

This one should be in M3. The summary up till now. There is mechanism to do timebombs. One of the problems was a preference problem. I fixed this and am awaiting permission to checkin. The timebomb's appear to work for viewer.exe. For apprunner.exe some of the functionality appears to work, but no alert's are being printed for the user. I'll continue debugging this. It is likely the user will be alerted of timebomb failure by being redirected to a resource: URL.

Hubie... Can you please change status of this bug to fix as soon as you checkin? Either Leaf or Sarah Broadwell will check that it works.

setting Chris Yeh as QA contact, Chris when your team verifies the fix, please mark the bug verified, thanks.

Well, currently the status is this: Assuming you define TIMEBOMB_ON when compiling nsNetService.cpp o win: non-netscape URLs disabled: yes warning message: no o linux: non-netscape URLs disabled: no warning message: no o mac: don't know There are 2 difficulties complicating solutions to this problem. o Disabling the URL depends on having pref initialized. Netlib has static initializers which get called before main() on linux. We initialized prefs in main() so this portion doesn't work on Linux (on win32 the static initializers get called when the library is first used, which is after main()) I can work around this by removing NET_CheckForTimeBomb's dependency on prefs for communicating timebomb info. o Warning message for timebomb expiration The warning messages don't work in apprunner because FE_Alert currently maps to nsBrowserAppCore::Alert() which decides not to output anything. The problem with a suggestion to redirect the URL is that netlib is being used to load many parts of the browser, including the chrome. At the levels where netlib gets control it doesn't know what is being loaded. The current notification mechanism was designed to be asynchronous in nature. I think the main problem here is netlib is being asked to do a function which long term should be the responsibility of the application. I could put calls into main() for nsAppRunner.cpp to check for expiration (via exported an exported netlib function) and load the 'expired' URL instead of the normal URL initially. Before I did this I wanted clarifications on: o is there a more simple solution? o is there some way to enable Alerts? o is it worth it to shoehorn this to work?

I'm adding chofmann to the cc: list. We *must* have some kind of timebomb implemented. I'm not sure if redesigning how the timebomb is implemented is the way to go, or if hacking this is the way to go.

We decided to move this to M4 since M3 is not a general release and even if we checked in something now, we'd only be disabling netlib for non-netscape domains. We wouldn't be notifying the user of expiration.

assigning to leaf. this should be working now, touch base with hshaw to figure out what needs to be done to turn it on and then test.

moving to m5

moving to m6 to get off of m5 radar. this isn't critical for m5.

reassigning to rpotts, based on conversation with don melton. idea was that rpotts was going to implement the time bomb settings in a js file. setting the target milestone out to m8.

Maybe I'm missing something here, but instead of manual hacking of the source, can't the timebomb date be passed in at compile time as a #define? Putting it in some sort of file would seem to make it easier for the user to change it (for binary releases at least).

m10

hey don, I'm reassigning this to you... gagan and I think that the timebomb should live at the webshell/docloader level rather than necko. So it's really an XPApps issue :-) -- rick

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

Nice dodge, rick.

Elevate to beta issue.

guessing no timebomb for m11. move to m12..

Move to M13.

Travis, can you handle this for M14?

Replaced "BETA" with "FEATURE" in summary.

Re-summarized.

PDT+

taking from travis.

unix and windows turned on. need to get the mac working.

Here is the documentation on TimeBombs: http://lxr.mozilla.org/seamonkey/source/xpfe/components/timebomb/nsITimeBomb.idl #26 It mainly talks about what preferences you need to set. You can put these in all.js: http://lxr.mozilla.org/seamonkey/source/modules/libpref/src/init/all.js This may change to be in config.js. I need to talk with Seth to sort out these details. Built on windows, is a tool called timebombgen.exe. It will generate the absolute and build_time dates. You can use the -c option to get the current time, or the -t XXX to get an time specified by XXX. XXX can be just about any format: http://lxr.mozilla.org/seamonkey/source/nsprpub/pr/include/prtime.h#225 If you have any questions, just let me know. If is not currently building on the mac, but it is working on unix and windows. The dialog you get sucks big time, but it is a start. Also, you sould publish a page that the user should be taken to when the build expires. This can be a XUL page.

Mac checked in. All is implemented. File new bugs against timebomb if they occur.

changing qa contact to granrose so that he can be cc'ed and perform testing and verification of feature

granrose, need to verify.

I've been told merging the xpt files into one large file (bug 29658) is higher priority than the timebomb due to the 10-15% startup performance improvement it gives, so I'm working on that right now.

Sounds good. I'll put verify by 03/10 in the Status Summary to give you breathing room :-) Thanks!

I can't get any of the timebombs to work. I'm assuming I'm doing something wrong on setting the relative timebombs. However, on the absolute timebombs on win32, I see a message on the console saying "About to expire" or "expired" but the browser hangs with only the splash screen displayed. If I remove the timebomb prefs from all.js, it starts up fine. I've emailed dougt, and I'm going to try today's win32 build to see if there's any difference.

What *is* the time bomb date? I'd like to know so I can help verify it as well as do negative testing.

Currently it's set for 10/4/2000 (see default/pref/all-ns.js). I've verified that that timebomb works, and the absolute timebombs work. But I haven't been able to get the warning to work, and haven't tested the relative timebombs yet. I'll try those tomorrow.

for the netscape commercial product, it is 4 Oct 2000 12:00:00. I doubt that this is confidential since it human readable in the prefs file, plus it is a long way away.

We just talked this out on PDT, and would like the date set the date to Aug 4th. This accounts for roughly a quarterly release cycle, plus an extra month in case something goes bad. It also sets folks up to "encourage" an upgrade to the next beta (which is something we're after). Is there a distinction between the "bomb date" and a "Nag date?" Is there anything else that needs to be specified? I have some recollection that even after the timebomb goes off, that the browser can still be used to contact *.netscape.com (to be able to upgrade). Is this also true? Thanks, Jim p.s., Sorry I didn't hear about this discussion before.

Lets open a new bug on reseting the timebomb to another date: http://bugzilla.mozilla.org/show_bug.cgi?id=31129 After speaking to micheall a bit, we found that there is no need for a nag date. Once the expire date is hit, a dialog will appear telling the user that they are running expired software, then they will be taken to a predetrimed home page. I am going to make this as fixed since the FEATURE has been implemented.

Marking Verified that this is in and new bug for Aug 4 date written and marked PDT+