Closed Bug 24839 Opened 23 years ago Closed 13 years ago

Need an easter egg in Mozilla

Categories

(SeaMonkey :: Build Config, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: michael.j.lowe, Unassigned)

References

Details

Attachments

(15 files)

No description provided.
Attached image image1
Attached image image2
Attached image image3
Attached image image4
Attached image image5
Mozilla needs some revenge.   See attached screenshots.
Priority: P3 → P1
Maybe Mozilla can breathe fire onto the IE e logo, which then melts into the 
ground. :-)
Summary: Need an easter egg for Mozilla → Need an easter egg in Mozilla
surely not ... it's trademark violation, for starters
michael.lowe@bigfoot.com, if you want to seriously propose an easter egg,
please file a new bug at an "Enhancement" severity level, add a [HELP WANTED]
code, and mention your RFE on n.p.m.general to let people know it's there.

What's proposed here, as amusing as it may be, could never be included in a 
shipping product, open-source or not.

Marking INVALID.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
sidr@albedo.net: whatever makes you happy.

> What's proposed here, as amusing as it may be, could never be included in a 
shipping product, open-source or not.

I'd like to know why not?   We probably couldn't user the exact IE logo, but 
there is nothing sacred about the letter e .    Reopening... upless you can 
mount a valid arguement why this can't be done, this enhancement request is 
valid.
Severity: critical → enhancement
Status: RESOLVED → REOPENED
Keywords: helpwanted
Resolution: INVALID → ---
Sure, Mozilla could use an easter egg, and dissing IE could be part of it,
but anything that involved scrawling over the images you attached would be
a no-go, for reasons of copyright infringement. It also wouldn't surprise
me if the "e" is trademarked by Microsoft for web browsers, and while that's
not sacred, in the context of a Mozilla easter egg it may be enough to get
some lawyers started, even if it was in a different typeface. Better not to
go there, and come up with something more original.

michael.lowe@bigfoot.com, I'm guessing you intended to suggest something 
involving original artwork, but you didn't use enough words to make that clear.
It would be unwise, if not invalid, to in any way use the bit patterns in the 
images you attached in an easter egg.
This is a general placeholder for anyone who might like to work up some form 
of clever easter egg.  The attached images are nothing more than an example of 
how Microsoft is making fun of Mozilla.

I'm suprised you guys are taking it so seriously.   Yes, I do understand 
the restrictions of copyright law, and I never mentioned anything about using 
other people's artwork.

So, time for some creative thinking.   This could be a good example of the 
capabilities of DHTML in Mozilla.
leaf?
Assignee: nobody → leaf
Status: REOPENED → NEW
Component: Browser-General → Build Config
QA Contact: nobody → gbush
i can easily come up with an animated gif for this purpose, but i don't have the
cycles to spare right now. I'm going to mark this remind, unless someone wants
to volunteer to own the bug.
Status: NEW → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → REMIND
Status: RESOLVED → VERIFIED
.
reopening to reassign to the Chocolatey Beatmaster.
Status: VERIFIED → REOPENED
Resolution: REMIND → ---
you go, boy.
Assignee: leaf → blizzard
Status: REOPENED → NEW
Status: NEW → ASSIGNED
Attached image Images 1-5 combined
Somepeople *Like* IE. How would you like a big N being destroyed? No windows 
icon destruction either.
how about an animation of us nuking redmond from space? ;)
Sounds good.  Maybe a real photo with Redmond, 2000 written in small print down
the bottom.  Then bang, and the text "Hmm, sorry about the residents, but it was
the only way to be sure!".
A pic with a Penguin, a big apple, and the sun logo getting destroyed by a
nuclear windows flag. Could we just have a moz icon? These ideas are kind of
being the equivlent of racist for computers.
Please ignore the spam.  Changing address.
Assignee: blizzard → blizzard
Status: ASSIGNED → NEW
busted from my reassign
Status: NEW → ASSIGNED
How about Mozilla versus Barney ?
I like the idea of Mozilla vs. Barney myself!  Prove that the Nice Guy(tm) 
*NEVER* wins, when big bad Mozilla breathes fire on Barney, and burns him to a 
crisp!
I think this whole conversation is _unspeakably_ amusing, but it might be a good
idea for the amateur trademark lawyers in the room to consider checking up on
``fair use'' and ``parody''.

As you were...
I vote that this bug be marked as a dup of bug 33302 ...
uh, why would you mark this bug a dup of that bug (resolved fixed)?  they really
don't have much to do with each other.
Because about:mozilla has always been Mozilla's easter egg, and anything else is 
just fluff. Having developers spend time on extra easter eggs would reflect very 
poorly on a project which is so deficient in other much more important areas.
oh whatever, developers need to have some fun from time to time.  People should
be allowed to work on whatever makes them happy and if someone wants to work on
this, they should.  I don't see how people (really) contributing (i.e. not
whining about stupid things) to a project can hurt anything or "reflect poorly"
on the project.
Hmm...  Actually, since "mozilla" is now Mozilla (the product), I don't see any 
need for about:mozilla anymore.  I think Mozilla needs a different easter egg 
from Netscape.  And I don't think just showing the credits and all the people 
who worked on it is enough.  I think we need something a little more FUN, like a 
cute pic.
Oh, phooey. about:mozilla was always about Mozilla, it wasn't about Netscape. You 
know, `And remember, it's spelled N-e-t-s-c-a-p-e, but it's pronounced 
"Mozilla!"'

But if you added to the about:mozilla page a picture of Mozilla (the lizard) 
grinning darkly at the user with their fingers in the victory gesture, *that* 
would be cool.
I agree, that WOULD be cool.  I say, let's do it!  However, what will we do

about the throbber, since it already has Mozilla anyway in Mozilla (not Netscape)?



Also, I think we need a new and improved activation method for this easter egg--

about:mozilla is too obvious now.

> ... but it might be a good idea for the amateur trademark lawyers
> in the room to consider checking up on ``fair use'' and ``parody''.

There's always someone who has to bring up the real world.  Shame on you!

I think that any mozilla easter egg should at least only be accessible through
about:mozilla, if not in about:mozilla itself.
How about this:
about: mozilla brings up an about page with a picture of the Lizard on it. Then,
if you click on the Lizard's eyes with the correct combination, (e.g. 3 clicks
on the left, 2 on the right, 1 on the left), the Lizard expands to take up the
whole screen, does a little dance, breathes fire, and then shrinks again.
I **LOVE** that idea.  I vote we do that...  I think that would be REALLY

classy.  What do you all think?

changing QA contact - 
QA Contact: gbush → granrose
fabulous idea!!!!  I think this should be nsbeta3, nominating as suck.  Come on,
this should put some zest and fun into all us testers' (and devs') lives :).  Go
Mozilla!
Keywords: nsbeta3
I'm working on this. Lots of JavaScript fun. I'm making about:mozilla compliant 
HTML/CSS at the same time (it would be ironic if bug 47108, once implemented, 
gave the big red X for `invalid' to about:mozilla).

I'm no artist, though, so I need a picture of the Mozilla lizard grinning darkly, 
about 128*128 pixels or larger. Do any such pictures exist?
Sorry to have to be an adult, but marking nsbeta3- per pdt review
Whiteboard: [nsbeta3-]
maybe this bug should be marked worksforme? "about:mozilla" is already implemented.
No, let's not mark it WORKSFORME.  In my opinion, 'about:mozilla' is not good
enough.  We need a *REAL* easter egg.  What's the point of 'about:mozilla', when
(especially in Mozilla as opposed to Netscape) it is so obvious now?  Surely one
of the qualifications of easter eggs is that they need to be *discovered* by the
user (i.e., an "undocumented feature" in the UI).  Besides that, what about some
of the other easter egg ideas discussed here?
How do you have an undocumented feature in an opensource project? If 
this gets checkedin (which it won't) everyone will see it in the checkin logs, 
and will BLAB to everyone.
Well, I was not necessarily saying that Easter Eggs had to be SECRET.  I'm just
saying "about:mozilla" is not special enough anymore...  That it is old and
tired. :-)

Here's an idea though: whoever wants to contribute the easter egg should have it
be accessible through a password or something, which could be encrypted in the
code, with a routine to de-crypt it.  After all, Unix store passwords in
/etc/passwd in encrypted form, and they are difficult to crack.  Maybe something
like this?

I do think we should have only ONE easter egg though, since we don't want to
bloat the product with too many. :-)
placing on the mozilla1.0 radar.
Keywords: mozilla1.0
I thought the whole point of dumping NS4 and rebuilding it as Mozilla was to 
remove bloat. It seems to me that adding easter egg(s) is counterproductive. I 
suggest a change of status to WONTFIX
How about a Mozilla gecko reclining next to some iced tea under an umbrella,
then he does something cool - he could send out that nuclear missile  (as said
before) with the press of a button and you could watch the missile from about
100 meters above as it leaves Mountain View, heads out into space and then lands
on Seattle.

I think it should be done somewhere other than about:mozilla. everyone knows
about:mozilla and people wouldn't have any trouble figuring out a combination of
clicking on the lizard's eyes. How about grabbing the Netscape logo with the
CTRL-SHIFT-N buttons pressed and dragging it to the words My Sidebar, releasing
should open a new window at 640x480 and show the movie.
Maybe 320x200 would be better. Mark: a 320x200 movie shown for 10 seconds at 5
frames per second using jpegs compressed to... say... 15% would be less than 1
meg. Sound isn't even necessary - except maybe a ping for pressing the button, a
cycling engine sound, and a boom sound. Isn't the sign of a better browser a
better easter egg? Remember the Easter Egg Microsoft stuck in office 95. It was
a 3d world.

Another idea I had was a lizard destroying the Redmond campus like in Rampage.
nominating for beta1.  I don't see how people are supposed to take the app 
seriously if it doesn't have an easter egg.  6.0 got ridiculed for this.
Keywords: nsbeta1
One concern is the size of the Easter egg...  maybe we could make the easter 
egg load up a URL from mozilla.org so that the burden of adding the easter egg 
would be very small. Perhaps a hash would be necessary based on the date or 
time or something to prevent people from bookmarking the URL, and to prevent 
people from stumbling into it through a search engine.  Also, this would allow 
the easter egg to change as the project progresses, and we could change the 
focus from what the easter egg should do... to actually adding some code to the 
project that would load up the easter egg. Since the easter egg could change... 
we could probably take submissions from everyone over time... and make alot of 
people happy that way.
Thats a good idea, except it will still have to be downloaded to their computer
anyway, then deleted. Some people also have slow connections, and some might try
the easter egg offline. I think the best thing to do is just not make it too large.

I think that as long as the easter egg is kept down to a meg or so, there will
be no problem.

Perhaps even to build on what you just say... a small 64 by 40 thumbnail could
play and give an option to download the easter egg. Then a text file could be
downloaded off the server and that would give the location of the easter egg ->
All without giving the url to the user.

I think that this might bog down the netscape servers though. It is probably the
best idea to send the easter egg with mozilla and update it when the people
update mozilla.
You really think that they would allow for 1MB of bloat added to the Mozilla 
install file (which is about 7.2MB right now) for a feature that is supposed to 
be really hard to find (easter egg), and few people will use, very rarely?

Also, it seems strange to assume that adding the easter egg to the source would 
result in less burden on the Netscape/Mozilla web servers than adding a URL and 
then loading when the easter egg is found. Also, if the traffic is too much of 
a burden... it would be easy to reduce the size of the DL. Even an XPI install 
of a special easter egg component could be located on the web server. Although, 
I don’t think this would be best, as it would take more time to implement.

Easter eggs generally have requirements for viewing them like... hitting keys 
in a special sequence... so adding the restriction of needing to be connected 
to the internet also falls well into the pattern of how an ester egg is 
supposed to work, especially for a public web browser.

And, your right there is nothing to preclude the idea that we could have a 
special small icon or something if they are not online when they try to view 
the easter egg.
Can anyone point me to a single sizeable easter egg in any app who's primary
distribution channel is download over a network where the average user is still
using 56k modems?  This bug would have a much better chance as an image, or
perhaps a CSS DHTML animation...
I like the idea of having the easter egg be at mozilla.org's servers.  This 
would allow for quite a bit of flexibility...  The *activation method* for the 
Easter Egg could be quite small that way (and more maintanable/changeable), and 
the Easter Egg itself could then be more maintainable/changeable.  I think the 
Easter Egg needs to be changed once in a while to keep it interesting, after 
all. :-)  I do also share the concerns of others about the Easter Egg being too 
big, too.
1 meg was actually the upper limit of such an animation but is way above what it
probably would be. In fact, a jpeg usually compresses to around 5% of the actual
24-bit bitmap at best quality (on photoshop). Therefore a 320x200, 10 second, 5
fps movie would be only about 480K if compressed at reasonable quality. Then you
could
shrink it down and degrade the quality. I guarantee you could get a 160x100
movie to be less than 100K and still look reasonably good.

Then there are vector graphics that could be used (like in flash movies), etc. I
don't think there is any reason it would be too large.

I guess an occasional user downloading the easter egg wouldn't be too much of a
stress on Netscape's servers. I just wonder if someone would wait for it to
download - especially if they are on a 56K. If it is being downloaded, the
people should definately get a message that it is downloading and the percentage
completed. The window could even show an icon that looks like an easter egg.
from slashdot:
For the record, the flight sim in Excel took a paltry 4K. It was just some basic
vectors and text list of the developers.
By contrast, the credits screen for Quake II took somewhere around 140K. (iD
fixed this for Quake III Arena, using just text on a 3D background).
OK, here's my idea. The easter egg is a method, of some sort, of activating a 
special, hidden URL. This method, and the URL, can easily change from version to 
version. We could also try and get the request sent to be special, so just 
typing in the URL wouldn't work. What's at the other end is a page which shows 
off all of Mozilla's cool capabilities, including the new ones in that release. 

So, for example if fixed positioning, MathML and SVG had just gone in, the demo 
page for that release would feature those three technologies. The pages would be 
uploaded to the mozilla.org server outside the CVS model, so people who checked 
out the html tree wouldn't get them. After a page had finished being an Easter 
Egg, it would go into some sort of gallery. Maybe.

This has loads of advantages. The Egg can be as cool as you like, doesn't bloat 
the download, we can have a new one each time, change it as often as we want and 
the wiring in merely involves writing a Ctrl-Alt-Double Click handler for the 
text field on some dialog box (or something.) 

What do you think?

Gerv
Attached image Lizard I drew :)
I drew these in about a half hour. They need a little touching up of course.
BTW - there is no need to tell how much these pictures stink. They are just
examples of what mpt described: a lizard grinning with a dark smile. Clicking on
his eyes in a correct combination could complete access to the easter egg, and
he could even blink when you click on his eyes.
Using a flash animation (vector graphics) sounds like a great idea. It should
keep the size of the easter egg small. The image could be pretty small (say 4
times the size of the throbber) and still look impressive. You could even tile
it as a background.
Boy... that didn't work. Save as a .dcr file and load in the browser (Need 
shockwave).
Ok, I believe this link will work if you have shockwave installed (not flash). 
http://www.geocities.com/mozillaman2000/bug24839/ - sorry about the mess-ups
Well, mozilla has a good ol' traditional easter
egg now:

<http://bugzilla.mozilla.org/show_bug.cgi?id=25369>

Can this bug die yet?
No ;-)
See also bug 68563 which has a nice idea for an easter egg.
I just had an idea: how about adding about:libpr0n as one of the easter eggs? 
It can show a 40's picture old guy in a bathing suit at the beach.
Attached image Mozilla Rampant
Attached "Mozilla Ramapant"
cc=self

*laugh* I couldnt resist joining in on the artwork-fun. 

As for this bug in general, I completely agree with Gervase Markham's comments
on 2000-12-13. That would be the ideal way to work things, giving a maximum of
spiffyness in an easter-egg, with a minimum of bloat/waste in an otherwise
more-or-less slightly serious project. 
cool work, but i have to remind everyone that mozilla is a red raptor not a 
green gecko. see http://www.mozilla.org/projects/svg/
Easy enough to fix. plus, now he shares more palette colors with the fire >:)
> Maybe Mozilla can breathe fire onto the IE e logo, which then melts into
> the ground. :-)

Yes, I suggest to use the same scene (cloned) as in the MSIE-easter-egg, but
longer: After the e stood there, Mozilla comes up again behind it and melts it.
This resembles the past, current and hopefully future market shares :).

More easter-eggs are better :).

> I guarantee you could get a 160x100
> movie to be less than 100K and still look reasonably good.

100K for 1 easter-egg are too much. I'd say at most 10K per easter-egg. Not too
hard, using MOzilla technologies intelligently.

As for Flash, go away. We have really cool "dynamic" technologies built right in
Mozilla. An easter-egg should also showcase them. SOUrce should be easily
accessible. This would show web developers, which cool things can be done with
JS, HTML and DOM (and maybe SVG?) only. No need for Flash.
Depends on: 68563
Pardon me for butting in, but I noticed this bug at level P1.  Is it really 
that vital?  We all like to have fun, but maybe the owner should reset this to 
P3 at best.
Of course not meant to be THE easter egg, I made an easter egg where if you 
type in the url "about:libpr0n", it gives you the easter egg which links to 
www.libpr0n.com. I will attach the zip file.
I thought that maybe this minor easter egg I attached could be changed to 
about:libgoat if people think about:libpr0n is innapropriate, and the link to 
the libpr0n site could be removed. 

What do you think? (I didn't write this patch just to have it ignored).

Pavlov - any opinions?
Depends on: 88760
Are there any opinions on about:libpr0n? I could change everything to 
about:libgoat. It would be an inside joke. You have to admit, that goat is 
funny.

Older Netscape releases had tons of about: this and about: that. What happened 
to that? I think that was really cool.
Blocks: 104166
This is definately a blocker for moz1.0 =-)
Depends on: 114912
As far as I can tell, this bug is fixed.

At random intervals I get a little pizza icon in the bottom right hand corner
next to the lock icon (in navigator) and next to the offline icon (in mail).

Clicking on it makes it go away, the equivalent of eating the pizza.
Whiteboard: [nsbeta3-] → FIXED?
*laugh*

Now we need an UI in the prefs panel so you can pick your toppings
I think that's supposed to be a cookie, indicating that a cookie has been set
or changed for that page.
Heheh. Anyway, an easter egg is something that is hidden from the user that
takes certain keystrokes, entries, etc in order to activate. If a cookie (or
pizza) appears in the bottom of the window for everyone, then it doesn't
constitute an easter egg.
sorry, someone decided there was too much of a performance hit to keep this 
easter egg (by default). it's gone now :o, you'll have to manually edit 
preferences to get it back.

note that netsite: in netscape4 counts to me as an easter egg and is rather 
similar to our pizza egg (if you ignore the performance hit).
*** Bug 132618 has been marked as a duplicate of this bug. ***
I think bug 122411 would make a nice easter egg. Atleast it'll keep me busy till
the Fishcam and drag&drop bookmarks are working again.
Product: Browser → Seamonkey
Assignee: blizzard → nobody
Status: ASSIGNED → NEW
Priority: P1 → --
QA Contact: granrosebugs → build-config
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Ever confirmed: false
QA Contact: build-config → build-config
Status: UNCONFIRMED → NEW
Ever confirmed: true
We won't add more easter eggs just because.
Status: NEW → RESOLVED
Closed: 23 years ago13 years ago
Keywords: helpwanted
Resolution: --- → WONTFIX
Whiteboard: FIXED?
You need to log in before you can comment on or make changes to this bug.