ss: Gecko Developer Preview has prematurely time bombed itself

VERIFIED FIXED in M1

Status

P1
critical
VERIFIED FIXED
20 years ago
8 years ago

People

(Reporter: Chris.Yeh, Assigned: angus)

Tracking

Trunk
x86
Windows 95

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

20 years ago
Turn on the timebombs so that the technology demonstration viewer app expires.
(Reporter)

Updated

20 years ago
Status: NEW → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → FIXED
(Reporter)

Comment 1

20 years ago
timebomb activated. Warning time is January 10th, 1999, at 00:01 am.
Expire time is February 1st, 1999 at 00:01 am.

No dialogs come up. All timebomb warning and expire information is spewed to the
console.

Updated

20 years ago
Summary: SS: Turn on timebombs for technology demonstration. → ss:Turn on timebombs for technology demonstration.

Comment 2

20 years ago
Changing SS: to ss: in Summary so that this bug shows up properly on queries to
be Verified.

Comment 3

20 years ago
cyeh, can you confirm that this is workink ok for 11/24 build and ark Verified
please?  should be in both viewer and xpviewer apps.
(Reporter)

Comment 4

20 years ago
i could, but that violates the basic QA premise that the person who made the fix
shouldn't be testing it.

testing this is really easy. just take your system clock, bump it to February
2nd of 1999, and then try and browser to URL's. It shouldn't let you.

I'm packing to leave on vacation at this exact moment, so I can't test it
anyway.

Updated

20 years ago
Status: RESOLVED → VERIFIED

Comment 5

20 years ago
Verified fixed (NT 4 SP 4 only).
(Assignee)

Updated

20 years ago
Status: VERIFIED → REOPENED
(Assignee)

Updated

20 years ago
Resolution: FIXED → ---
(Assignee)

Updated

20 years ago
Summary: ss:Turn on timebombs for technology demonstration. → ss: Gecko Developer Preview has prematurely time bombed itself
(Assignee)

Comment 6

20 years ago
Reopening bug so we can track this. Adding people to cc: list. Modifying
subject.
(Assignee)

Comment 7

20 years ago
Can QA please verify that despite Gecko's claim to be "expired," that it does
indeed function properly?

Can Rick Potts or someone else in the know explain that this is expected
behavior?

If it really does work despite being "expired," I propose updating the Gecko
Start Page and Release Notes to document this as a bug, and explain that an
updated build will be available in February when we had originally planned for
this time bomb to expire. Thoughts?

Comment 8

20 years ago
paulmac - checking bug now....hang tight....he's the man!

Comment 9

20 years ago
Unfortunately, the time bomb is working correctly (however prematurely). You can
only surf to the netscape.com domain. Anywhere else won't let you load the page.
Whoops. So we need to get this fixed and posted.

This is for both ngt.exe and viewer.exe.

Comment 10

20 years ago
the build I have still looks good to me.

I think its a build from dec. 3.

I can go to http://www.yahoo.com and other sites
with no problem on my win95 laptop.

I've up the build on http://grok/u/chofmann/seamonkey.zip
can someone try this out and see if they get the same..

Comment 11

20 years ago
the build I have still looks good to me.

I think its a build from dec. 3.

I can go to http://www.yahoo.com and other sites
with no problem on my win95 laptop.

I've up the build on http://grok/u/chofmann/seamonkey.zip
can someone try this out and see if they get the same..

Comment 12

20 years ago
I used the Dec 4 build off sweetlou and paulmac used the Dec 4 download from
mozilla. Both of us had the problems he described.

The Dec 3 build was not the final DevPrev build.  I checked yours and yes, it
works.  But you have xpviewer as the exe, and we changed the name to ngt with
the Dec 4th and final DevPrev build.  So, what folks have on their floppies and
the one we posted to mozilla is indeed the build with the problem.

Comment 13

20 years ago
Hi.. I just downloaded the win95/nt binary from mozzilla. Im getting the time
bomb to when I run ngt.exe I wont let me surf.. Hope this helps
(Assignee)

Comment 14

20 years ago
Ok, I'll recommend that DevEdge do the following:

1. Pull the download link to the Developer Preview build
2. Update the Gecko Start Page to contain a paragraph explaining the problem
3. One of the following:
   a) Encourage users to download the latest nightly seamonkey build
from              mozilla.org
   b) Tell users to wait for a new release "coming soon"

I need feedback from chofmann and chriss (and others) on 3a vs. 3b.
(Assignee)

Updated

20 years ago
Assignee: cyeh → angus
Status: REOPENED → NEW
(Assignee)

Comment 15

20 years ago
QA has verified that although the Dec 3 build doesn't have this problem, it
doesn't have any form of a timebomb that works. So, here's the current
recommendation:

1. Note on the Gecko start page that the current release has expired and as a
result, it will work only on netscape.com URLs or on the built-in sample files,
or other files residing on the local computer. We will also explain that an
updated version of the release will be available in February.

We may additionally explain that for those who are particularly adventurous, a
nightly build, which is much less stable, is available every day on mozilla.org.
We won't link directly to the download, but will instead link to the mozilla.org
binaries page which provides a scary warning.

Any objections to this plan?

Comment 16

20 years ago
I agree that this is what we should do.  Currently the start page has been
changed to say "a newer version coming".  This needs to get corrected ASAP.

Comment 17

20 years ago
lets do it!

Comment 18

20 years ago
Currently checking Dec 3, Dec 3a and Dec 4 builds for fileset diff.  Will decide
on replacement of Dev Prev after the the results are in.

Comment 19

20 years ago
So, where are we on this.  Did Angus pull unneeded files and wehave a new build
for QA to check?
(Assignee)

Comment 20

20 years ago
I have pulled the files and am extracting the unneeded stuff, checking to make
sure it works in a safe directory (so when I rezip, it doesn't get _my_ cache
:-). I'll have something for QA to check at 12:30 pm today. If we send to
DevEdge tonight, it should be live tomorrow morning.
(Assignee)

Comment 21

20 years ago
I have pulled the files and am extracting the unneeded stuff, checking to make
sure it works in a safe directory (so when I rezip, it doesn't get _my_ cache
:-). I'll have something for QA to check at 12:30 pm today. If we send to
DevEdge tonight, it should be live tomorrow morning.

Comment 22

20 years ago
Will put together QA testers. cyeh, please send build-ready announcement to
marvin-qa.
(Reporter)

Comment 23

20 years ago
clarification: bits need to get to me, not dev-edge. the ftp url is served off of
the mirrored public ftp sites, which i control.  just let me know which bits to
grab, and they will get pushed and mirrored inside of a few hours.

Updated

20 years ago
Status: NEW → RESOLVED
Last Resolved: 20 years ago20 years ago
Resolution: --- → FIXED

Updated

20 years ago
Status: RESOLVED → VERIFIED

Comment 24

20 years ago
Okay, this bug can (finally) be closed. Good job. :-)

Comment 25

20 years ago
Inserting Milestone info.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.