While triaging RFEs, DUPEs, WFMs, INVALIDs, UNCOs, and the occasional valid bug, I realized that there is a request to add everything but the kitchen sink to Mozilla. I feel this is a severe shortcoming, and needs addressed. I'll see what I can do about adding a patch shortly.

assigning to self. We need a "home appliance" component too.

didn't take last time. Let's see if I can get it right this time.

I have enough bugspam to last me years

I can confirm that Mozilla does not have a kitchen sink. When you fix this, could you give it one of those really loud garbage disposals, for dealing with non-standard pages? Twiddling some widgets on this bug because I'm testing the new xbl form controls and because I'm bored ;-)

I contacted a plumnber about this last week. He started working on it and it was all going fine except for the constant stream of hot drinks I had to provide (bug 46647 would help here). Then he told me that actually, it was going to take a lot longer than expected and would cost far more than the quote. Much like Mozilla 1.0 really. ;-)

A kitchen sink. I'm working on creating it's own about: so everyone can see that Mozilla is the only app that has everying AND the kitchen sink (unlike Emacs).

Adding Chris Aillon to the CC list. I think he may be able to comment on the previously attached sink.

Well, at least this kitchen sink is valid xhtml 1.1 and css...

Not too bad. Let's see you put a <span></span> around each letter and set them all to display: none at first, and use some DOM JS to make them all appear "one pixel at a time" :)

Err, I meant |visibility: hidden;| Your loop is a simple one like this: var ascii = document.getElementById("sink").getElementsByTagName("span"); if (ascii) { for (var span in ascii) { span.style.visibility = "visible"; } }

I'll see what I can do. I'm currently hacking nsNetModule.cpp and nsAboutProtocolModule.cpp so there is an about:kitchensink URL. Of course, I'm also going to see if I can avoid that, because I'll have to do a CVS pull, and create a build environment... I think putting every character in a span would increase the size by at least a factor of 13. That's assuming that we don't have to name any of the SPANs. I'm tempted to create a JS compression scheme to cut down the size. ;) Notice how we're adding lots of features to a bloody joke? Now that Mozilla will have a kitchen sink, we're still not satisfied. :)

If you can get someone with checkin priveleges to put this in the tree, i'll add the code to show this about page.

Comment on attachment 67056 [details] A kitchen sink. Of course not. We haven't had 1.0 yet. Needs some JS to simulate water running.

Man, that would be sweat!

jesusx: I'll make the patch for the about:kitchensink as soon as you do the running water. It really shouldn't be too hard. You can make divs of groups of letters and have them start out at the top and travel down (maybe two groups at a time) and have them sway and get closer together as they travel down towards the drain. When they hit the drain, cycle them back up to the top. This is DEFINATELY a 1.0 blocker ;-)

Also, please make it so that when you click on the handle, the water toggles on and off :-)

You gotta love it :-) I decided to do this because I want to implement this bug along with bug 60085 so I hack both abouts at the same time.

You have *way* too much time on your hands. :-)

Comment on attachment 72037 [details] A Kitchen Sink With Running Water Hmm, it doesn't validate properly any more. For advocacy reasons, I think that it's essential that all Easter Eggs comply to Web standards.

It seems that the water doesn't appear in the same place on everyone's browser.

> It seems that the water doesn't appear in the same place on everyone's browser. On my system (2002022203, Windows XP) the water flow seems too wide. It appears to fall out of the tap but also the part to the left. It's more obvious if you turn the water off.

I replaced 4pt with 6px. Hope it works on all platforms.

If its tested by a lot of people and it works, I will make the water mesh better with the sink.

You know how these kinds of things go...

The most recent one (attachment 72057 [details]) is pretty much perfect. But... The water flows faster than in the others. Any chance of slowing it down (it looks more realistic that way)?

> The water flows faster than in the others. Any chance of slowing it down (it > looks more realistic that way)? Scratch that. I wasn't thinking. The faster version is far superior.

Just noticed something: the animation doesn't play nicely with the View > Text Size feature.

A solution might be to introduce the text directly into the sink div.

All others are obsolete

I speed it up significantly by pre-buffering.

Not that it really matters, but can someone figure out why it isn't displaying right on IE?

For some reason, attachment 72289 [details] was HTML 4.01 and not XHTML 1.1. I can't understand why as with a few changes, it's possible to make it validate as XHTML 1.1.

Why do you want it to be XHTML and not HTML 4.01?

> Why do you want it to be XHTML and not HTML 4.01? Because XHTML is new and exciting, of course! The original patch provided by Grey Hodge was XHTML 1.1 so I don't see any reason to change.

um ... how about adding water level for it :) LOL keep on the good work !

The latest versions handle a text size increase but not a text size decrease.

Any chance of making 'the lizard' 's head pop out of the plug hole ?

re comment #36 and #38. Now you are going a little bit overboard :-) re comment #37, i'll look into that.

I hate to be someone to stop up the drain, but would you mind cleaning up those two strict warnings 72289 gives me? "assignment to undeclared variable". No sense having a great animation slow down the suite.

comment #13 by alex appears to be a bug in Mozilla. Try loading it with text size already 50% and it works fine. Enlarge it and shrink it and it works fine. Anyone else agree this is a bug? The scrict warnings were fixed.

Sorry, I meant comment #37 appears to be a bug. Sorry for the spam.

There's a small bug in the latest version which prevents it from validating. To fix it, change line 284 from '<td><pre id="sink"><pre>' to '<td><pre id="sink">'.

cool ... but the target (0.9.9) has passed already. When will the kitchen sink get into Mozilla? May be 1.0?

Will Mozilla post it via UPS or DHL...DHL sucks anyway so maybe UPS is better, but how about customs etc. :D

http://bugzilla.mozilla.org/attachment.cgi?id=81359&action=view In this attachment resides the fix to this bug included with bug 60085.

Anyone knows will the kitchen sink get into Moz1.0?

> Anyone knows will the kitchen sink get into Moz1.0? I highly doubt. It would only happen if bug 600085 gets in and this piggybacks on it.

That should be bug 60085.

There is a problem with the last attachment ( http://bugzilla.mozilla.org/attachment.cgi?id=76401&action=view ). On reducing the font size, the two sink halves get separated. Could this be fixed before inclusion into the tree?

Apologies for that last email. (References to comments already made) However, I would vote for coloring the water "lightblue" for maximum effect. This goes on to show easter eggs are not all black and white.

Christopher: I tried that a while back, and it didn't look that good.

You should use Internet Explorer that comes with an old tin bath that you have to carry around the net with you when you use it its called Non Standard Activex!

You should use Internet Explorer that comes with an old tin bath that you have to carry around the net with you when you use it its called Non Standard Activex!

RE: bug 60085. I was working on inserting just this command into the about: protocol before I fell ill. I didn't look terribly difficult. It's probably the best way to get this into 1.0, since with 60085 gets fixed, the current about: implementation will be redone. Grey Hodge [not quite dead]

what are the chances of seeing this get into 1.0? I looked at the about code and it seems like its basicly adding the HTML file, modifying the jar.mn file to pull it in and then adding about 5 lines of code to nsNetModule.cpp and 1 to nsAboutRedirector.cpp I can whip up a patch if need be, it wouldnt take very long.

Re comment #56, comment #57. I have already done that. They now want the about:commandline page to be dynamic.

I want to use this bug as an example bug in a lecture, because it's cool. So I want to obsolete some attachments to show that. The only way to do this with minimum spammage is to add a new attachment. So, this is the same attachment again. :-) Gerv

Comment on attachment 76401 [details] Validates - all others obsolete r=gerv. ;-) Gerv

Since 0.9.9 and 1.0 are out the door...

Comment on attachment 76401 [details] Validates - all others obsolete fixing which patch has r=

The sink breaks if I zoom out using Ctrl+-.

Trying this new aka feature for quicker access to this bug. If it doesn't work, can I pour it down the drain or is there problems with that?

I can't _believe_ you are seriously considering this. I most definitely hope this never gets sr, because it just bloats Mozilla for no use whatsoever.

The kitchen sink is about 20KB, compressed with gzip it's about 5.7KB, making it about half a promille of a complete install download.

biesi: if that were a criterion for sr=, most of the current tree would never have been checked in ;-)

Jesse: Would you or someone else be able to track down what causes that? I can't figure out how changing text size should cause that. It seems like a bug in Mozilla.

the problem with adding this to the tree isn't the added bloat, bur rather: if mozilla should have an easteregg, should this really be it? (for the reckord, i think it rocks!) Or should we have more then one, and who/where/how would we decide on which eastereggs to have. IMHO eastereggs just doesn't go that well in opensource applications, unfortuantly. Especially not in an application that isn't really ment as a finished app, but rather something for others to redistribute. Compare it to adding an easteregg in the Linux kernel; I would be very surpriced if that happend, but RedHat or Lindows could perhaps add an easteregg in their distribution of linux.

I thought that there's something like a "mozilla only flag" which can be set for compilation(?). The other "problem" is, that an easteregg has to be somewhat difficult to find. With a public bug report like this, it will be known within seconds after checkin. If this goes in _somewhere_, this bug would have to be blocked from view like a security bug. And then there's the question whether eastereggs are the privilege of "real core mozilla hackers". I really like the kitchen sink, it's much less bloated than most of the eastereggs out there.

I like the sink too, don't get me wrong. But as you say, eastereggs should be hidden, and having this in the main tree will make it all but hidden, marking this bug as blocked for security won't help, lxr and bonsai will still show it in all its glory. What I would recommend is that someone makes an xpi that hooks this up. That way it'd be easy for distributors (like netscape) to hook it up and it would be much more hidden then if it was in the main tree. btw, what happened to the suggestion of making the water light-blue, that sounded pretty cool to me.

The way the about: handler is, I think we'd have to completely rewrite it if we want to be able to plug new things into it. (actually, I'd like to see it rewritten for that, but anyways...) Just to add about:kitchensink would require changes to the handler code itself. Anyways is it really that bad that we'll know it's there? What about people who simply use Netscape or other browsers based on Mozilla? They probably won't until someone "stumbles" upon it and starts mentioning it to others, right?

/me still thinks you all must be out of your mind What does the module owner say to this (darin)? Darin, would you say this is WONTFIX or should it be fixed? (this is in the about: code, therefore networking) WTF is the QA Contact of this bug the same as the assignee? Oh I see, b-g QA wanted to get rid of it... restoring QA contact to default qa.

I think we should donate this easter egg to Emacs once it embeds Gecko (http://groups.google.com/groups?th=b57da495a1d20aaa).

Re comment #72 - No, it requires about 5 lines change. There is a redirection handler in the about protocol that handles any URL redirections. I already have this code written (See previous comments). Its just the code I was going to piggy-back it on about:commandline was not accepted because they want it to dynamically grab the commandline info.

Re comment #72. There is sites dedicated to easter eggs, and people might actually be disappointed there are no easter eggs in Mozilla. Some people actually have no life ;-)

Re comment #70. Most people like easter eggs because they are clever and interesting as opposed to impossible to find. Yes, they should be somewhat obscure, but easter eggs - through word of mouth and various web sites - don't remain a secret for long. Most people that will enjoy the easter eggs don't read the source code of Mozilla. If you are worried about a "leak" from developers or bugzilla.mozilla.org users about the easter egg, realize that employees of closed-source programs also "leak" information about easter eggs to friends, etc.

Sorry about the multiple comments. I did the wrong thing and replied as I read the emails as opposed to all at once because I thought I wouldn't reply to another one. Re comment #69: My belief is that we should have multiple easter eggs, and remove them in exchange for new ones on occasion when newer versions of Mozilla are released. I don't think easter eggs and open source are an issue since there is much more to an easter egg than its obscurity. Re comment #71: I tried colors, etc. It not only slowed down the code, but didn't look all that attractive.

I only took a quick look at this bug, but if you are going to make it available via about:, please put that in the subject at the front. In networking, I like my protocol handlers on the left :)

Since this really is taking on a life of it's own, changing a few items of the bug. I'll see about a minmally intrusive about: protocol patch...

(left). Someone should get practice for a good job, and take QA of this.

the kitchen sink is not an easter-egg; it's rather a personal touch in mozilla that represents the open-source-comunity (some crazy people working on their project and having fun doing this) would be nice to have some 'personal touchs' in mozilla / accessible from 'about'-protocol (you can tell the enduser, this is the browser-saver or coffee-break-display or something like this)

jesusX: The patch is easy... I can create one in about 20 min. Its getting it into the tree that is the hard part... ;-)

The "final" version (attachment 86945 [details]) may validate per the automated validator, but it is not actually valid. It uses tables for layout purposes, and it uses invalid DOM extiensions such as "innerHTML".

Hixie: innerhtml is a de-facto "standard" even if its not part of the w3c recommendation. The only other alternative that I know of would be walking the tree and inserting new values. the DOM open, write, close wouldn't work in this case, would it? I'll fix the tables part. Word is that we might be able to get this onto m.o next to expando http://www.mozilla.org/newlayout/demo/expando.html

Why don't you just use DOM core and change the contents of the text node directly? There is absolutely no reason to use innerHTML nor open/write/close here.

fwiw, I would be ok with putting the html page on mozilla.org and just make about:kitchensink use that (the patch would be a one-liner)

willseatery@yahoo.com, please don't waste peoples' time nominating non-bugs like this. Thanks.

Hixie: I fixed the DOM stuff, but I can't get the document to layout correctly using the CSS2 table model because it has no way to do the equivalent of "colspan". Here is a skeleton of the page: <div style="display: table; table-layout: fixed; border-collapse: collapse; border-spacing: 0;"> <div style="display: table-row;"> <!-- Start Table Row --> <div style="display: table-cell;"> 1 </div> <!-- End Table Row --> </div> <div style="display: table-row;"> <!-- Start Table Row --> <div style="display: table-cell;"> 2 </div> <div style="display: table-cell;"> 3 </div> <div style="display: table-cell;"> 4 </div> <!-- End Table Row --> </div> <div style="display: table-row"> <!-- Start Table Row --> <div style="display: table-cell"> 5 </div> <!-- End Table Row --> </div> </div> It should appear as: +-----+ | 1 | +-+-+-+ |2|3|4| +-+-+-+ | 5 | +-----+ yet it appears like this: +-----+ | 1 | +-+ +-+-+ |2| |3|4| +-+---+-+-+ | 5 | +-----+ Does CSS2 has any way to define the structure of the way it should appear?

it seems like attachment 86945 [details] works better.. fixed everything? hmm

CSS2 doesn't have colspan/rowspan equivalents yet. We should, however, implement -moz-column-span and -moz-row-span or some such.

I may have missed something, but why cant we use tables in this?

nb: Its not important because my new version has no tables, nor any CSS tables, it uses straight DOM #text node editing. Because standard CSS doesn't allow for colspan and rowspan, table would be the only way to go that I can see besides what I mentioned above. I believe (not 100% sure) this is because CSS was intended to be downwards compatible with text-based browsers, etc. The issue here is this page isn't made to view with any text-mode browsers as obviously it is a graphical page and is intended for use with graphical browsers and isn't made for entertainment purposes. Using a mozilla-only extension of CSS would be breaking the standards (-moz-column-span), and I assume it would be best to put it up in demos as a standards-compliance page. No issue, the DOM supplies all I need to do it through the DOM on a large block of text as opposed to within tables.

Now I feel compelled to speak up. I created this as a joke. Then it morphed into an easter egg for Moz. As such, we can use Mozilla-only features, because this isn't MEANT to be viewed in other browsers.

I made it use the DOM, put a little demonstration in it to show people how to do it, and it no longer uses either table or div, but inserts the text directly. I just have to reinsert the code for the water and clean it up a bit. :-)

Has a nice little DEMO of how to work it. This is it.Hope you like it :-)

BTW: NS 7.01 doesn't display the shading behind the handle. You need to use it in a newer browser.

Bah, _some_ people are _so_ picky ;-)

"!!!FINAL!!! version :-)" has been committed to webtree as http://www.mozilla.org/catalog/web-developer/examples/kitchensink.xml Bug is not fixed yet, as we still need r/sr to make about:kitchensink

I can make it, but I won't until I get validation something like that would be checked in. :-)

The one on the web seems to crash all versions of Mozilla. :-/ The attachment doesn't. That's strange. Something to do with server settings or something? Nicholas: Whatever it is, we don't want to lose that testcase. I would try to reproduce that crash issue on another hidden file on the server before you fix whatever is wrong with server settings that cause kitchensink.xml to crash on the server. Then, we will have a testcase for filing a crasher bug.

I meant Mozilla freezes. It eventually brings the page up. The content of the page seemed fine on http://www.mozilla.org/catalog/web-developer/examples/kitchensink.xml but look at the content-length http header. AHA! These are the HTTP headers I grabbed using http://www.wannabrowser.com/index.html for http://www.mozilla.org/catalog/web-developer/examples/kitchensink.xml: HTTP/1.1 200 OK Server: Netscape-Enterprise/3.6 Date: Thu, 13 Feb 2003 05:54:02 GMT Content-type: text/xml Etag: "5be90-5215-3e4b1c1d" Last-modified: Thu, 13 Feb 2003 04:16:29 GMT Content-length: 21013 Accept-ranges: bytes Connection: keep-alive http://bugzilla.mozilla.org/attachment.cgi?id=114190&action=view: HTTP/1.1 200 OK Date: Thu, 13 Feb 2003 07:29:03 GMT Server: Apache/1.3.26 (Unix) mod_throttle/3.1.2 Content-Disposition: inline; filename=kitchensink.xml Content-Length: 20400 Content-Type: text/xml; name="kitchensink.xml" My site: HTTP/1.1 200 OK Date: Thu, 13 Feb 2003 07:18:45 GMT Server: Apache/2.0.40 (Red Hat Linux) Last-Modified: Wed, 12 Feb 2003 08:17:07 GMT ETag: "49c51b-4fb0-d47486c0" Accept-Ranges: bytes Content-Length: 20400 Connection: close Content-Type: text/xml X-Pad: avoid browser bug

Checking http://bugzilla.mozilla.org/attachment.cgi?id=114190&action=view using the built in button results in "This page is not Valid XHTML 1.0 Strict!" when I'm using my Proxomitron. IMHO, http://bugzilla.mozilla.org/attachment.cgi?id=86945&action=view is prettier, and perfect if it would just display the tap handle in the off position while buffering. I was pleasantly surprised when I found out the clickable handle on my own. :) Both pages validate as XHTML 1.1 when checked manually.

Nevermind, the font was too big. And I like the additional water animation and same click area for on and off.

Comment on attachment 114190 [details] !!!FINAL!!! version :-) Nearly there -- this is almost perfect. The only remaining issues I see are: (a) do we have to use red? In test cases red means usually means bad. :-) How about blue or green or something? Or just leaving it as the default colours, which would be best. If we do change the colours, we should set the color and the background together. (b) We should use pixels or, even better, 'em's for the font-size, not points. (c) We shouldn't have the button, IMHO. It looks silly. And it won't work anyway if the URI is about: anything.

Yeah, those are good points. I fixed the colors, sizing units (ems!), margin on the joke, and removed the validation (and some misc cleanup). That was really just to be part of the in-joke before this bug took on a life of it's own...

Update has been committed as http://www.mozilla.org/catalog/web-developer/examples/kitchensink.xml Should be changed on moz.org in about 15 mins.

Attached is a patch to enable about:kitchensink

Attached is a patch to enable about:kitchensink This is for the second file that needs to be modified.

Comment on attachment 114921 [details] [diff] [review] Patch to enable about:kitchensink r=dougt very funny.

Comment on attachment 114921 [details] [diff] [review] Patch to enable about:kitchensink kRedirMap is searched linearly, please move this to the end of the list. sr=darin with that change.

changing target milestone so it's no longer in the past.

Comment on attachment 114922 [details] [diff] [review] Second patch to enable about:kitchensink - both are needed >Index: nsNetModule.cpp > * Contributor(s): >+ * Nicholas Bebout format of this is: * Contributor(s): * Nicholas Bebout <nb84@evansville.net> sr=darin with that change =)

ok, so now that the patch has the r=/sr= necessary to land this on the trunk whenever it opens (because it is technically done right), someone care to explain why we want this in mozilla? do we really mean to be so self deprecating? yeah, i see the humor in this, but i'm not so sure that this is something we should be adding to netscape, mozilla, chimera, phoenix, galeon, kmeleon, etc. someone care to explain why we should?

Comment on attachment 114985 [details] [diff] [review] Revised first patch Carrying over r= from dougt and sr= from darin

Comment on attachment 114986 [details] [diff] [review] Revised second patch Carrying over r= from dougt and sr= from darin

advantages: cool, funny, low cost, ultra low footprint, is a neat demo of using the DOM and JS to acheive simple yet elegant results. disadvantage: wrongheaded people think that we're wasting our time and bloat the product (well, we do, but not because of this) It's already done, so the time is wasted regardless. Checking it in will make it less of a waste. If nothing else, it shows the world we're good humored about ourselves. :)

This is inappropriate to shove down the throats of other projects that will be forced (as the patch stands) to accept this "feature". Phoenix and Chimera and other Gecko projects don't want this, don't appreciate the humor (since they are explicitely not "kitchen-sink" applications) and shouldn't be forced to accept it no matter how small or cute some Mozilla developer thinks it is. Until this can be made to only affect the Mozilla suite and not other embedding apps the patch cannot be allowed to land. In light of the undesirable impact on other gecko-based apps, I'm explicitely requesting that darin and dougt withdraw thier reviews.

Comment on attachment 114986 [details] [diff] [review] Revised second patch give me a break. people need to stop writing stupid patches and stop wasting peoples time trying to get them checked in to the tree. If this goes in, I'll back it out.

Comment on attachment 114985 [details] [diff] [review] Revised first patch agreed

Comment on attachment 114986 [details] [diff] [review] Revised second patch >Index: nsNetModule.cpp [...] > * Contributor(s): >+ * Nicholas Bebout <nb84@evansville.net> Nit: still missing Darin's request to format this properly.

If I view this in Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.3b) Gecko/20030211 it is extremely slow and makes Mozilla very unresponsive. Also, the formatting is completely bodged so it doesn't look like a sink. Not a good thing at all! It goes fine on an identical hw spec machine running XP however. I'm running the Mozilla XFT build, which is probably why!

Sure, it's cute, and the tradition of strange easter eggs in web browsers goes back a LONG way. But we have cute easter eggs already, and IMHO this isn't cute, funny, or compact enough to justify itself. Moreover, EMACS claimed the whole 'kitchen sink' joke territory many years ago.

The reason it makes Mozilla really slow is a problem with the mozilla.org webserver. If you try to view the last attachment of the .xml file, it works perfectly, it just doesnt work when you try to view the mozilla.org version. I think it may be a problem with the headers or something. Look above for where someone pasted the headers from bugzilla.m.o and www.m.o. I'll look and see if there is a way we can only enable this for Mozilla. If that is fixed, would it be able to land?

it would not be able to land. Drivers are against it, and the patch has no super-review.

> it would not be able to land. > Drivers are against it, and the patch has no super-review. no no no, I think he means if he finds a way to enable this ONLY for mozilla, and not phoenix, chimera, and the other mozilla-deriatives.

This brings up a rather serious point: Phoenix is Mozilla. It takes the HTML editor association, and occasionally confuses itself with Mozilla. It wouldn't be hard to make the about:kitchensink draw a 'blank' in phoenix or even render a different page 'Phoenix will never be a kitchen sink. Phoenix *will* be standards compliant, stable, and will support the Mozilla plugin API, but beyond that it is its own beast.' ..something like that.. Sam

this would compete with the fishcam (ie flush the poor little fishies down the sink). -> Wontfix for the sake of them fishies.

Not your bug, kthx.

It is only a demo of a XML webpage with certain scripts... Not that it is part of the browser's feature such as the Back Button, Javascript Console, History Session, Tabs, etc..., which explain why people don't want it to be part of the browser. So, how about donating this 'Kitchen Sink Project' to "http://www.mozilla.org/start/1.0/demos.html" OR SOMEWHERE as a demo of what XML can do for Gecko... Just a suggestion, not a requirement...

Personally, I see no problem with having this just on the web server, and not having an about page. Even though that would be kind of cute, I never thought that was a realistic hope anyway and turning this into another splash screen bug will mean we never will have a good examples sections. Let's accept Asa's judgement based on years of experience and work on mozilla.org's examples section. Asa: Can we have review+ and superreview+ based on this going on the Mozilla site (which has already occured) and not altering the Mozilla tree in any way? Or is that not necessary/applicable? nb: I'm curious at what the issue on the web server is as it doesn't seem to be happening anymore, but I know it happened in the past. Is it fixed? Re last comment: http://www.mozilla.org/catalog/web-developer/examples/kitchensink.xml Refactoring all the examples into a central location under which this example will reside is something that would be valuable (especially for regression testing) and has been my intention ever since someone pointed me to the expando example (comment #85), because I believe good examples are a wonderful way to introduce someone to the standards. The issue I saw is that most of the examples are strewn around the mozilla.org site in outdated sections and pages that hardly anyone goes to anymore. In fact, good examples don't have to even reside on our server for us to link to them, as long as we know they will remain standards-compliant and in their current location and we have a way to contact the writer. All we need is a page that stays updated and is a central location for all examples' links and descriptions. We could have: http://www.mozilla.org/catalog/markup/examples (Better than web developer as XUL is markup but not web-based per-se) with an index page containing the following sub-sections with links to examples: HTML, XML, XHTML, XUL and anything else anyone can think of. DOM/CSS/JS examples could appear under the section based on what doctype they affect. Each section would also have a target, such as <a name="#XHTML"> that could be linked to from ,i.e., the XUL documentation for the XUL examples, and the HTML documentation for the HTML examples. Each example on the page could have a one line description, and two links, one to the example, and one to a page describing how the example works. Skeleton: XHTML Examples Kitchen sink - Uses javascript and DOM text insertions to create an animated interactive ASCII art sink. [View] [Description] HTML 4.01 Loose Examples Blah blah HTML 4.01 Strict Examples Expando - Dynamically changes CSS properties of text to create a nice affect [View] [Description] CT: (comment #103) This is final barring standards issues. Anyway, I'm glad you found it, but some people would not find it on their own. Not everyone is creative and inquisitive in the way they would discover something like that on their own. Since this is an example, and not an easter egg, its important they know what the page does.

>Can we have review+ and superreview+ based on this going on the Mozilla site Webpage checkins do not require review/super-review

I think a kitchen sink done in SVG would be more flashy. The SVG could be generated or animated by javascript... Anyone up to the task? :-)

err, lets try a more direct summary.

How about we leave things nice and simple, ok folks? Unless someone has a patch-in-hand so this builds _only_ in Mozilla, let's let this alone for a while. It's funny, but not a priority one issue.

Moving -> mozilla.org

I would love for this to make it into Netscape 7.1. Any chance of getting one of the latest "sinks" in Moz 1.4?

Did you know this was slashdotted on February 22? http://slashdot.org/articles/03/02/22/1420228.shtml?tid=154

Chris: word is we can't get it in unless we can make it only appear in XPFE version, and nothing else. This is especially inappropriate for Firebird since its not made to be bloated. This does bring up an interesting point, though. We should be able to have independent about: pages.

>we can't get it in unless we can make it only appear in XPFE >version, and nothing else I wonder, who said you can get it into the xpfe version? > We should be able to have independent about: pages. what stops you from doing that?

> I wonder, who said you can get it into the xpfe version? I've heard it various times, look at: comment 120 > what stops you from doing that? Because putting it in there now would mean that embedders, and any other gecko-based browser would be forced to have it also. If you mean why don't I modify the tree to allow independent about: pages, its not any kind of priority, i was just answering a question.

>Because putting it in there now would mean that embedders, and any other >gecko-based browser would be forced to have it also. not necessarily... > If you mean why don't I >modify the tree to allow independent about: pages, if I understand what you want correctly, then that is already possible... just implement nsIAboutModule (iirc) with the right contractid

I hope I didn't break anything. http://www.mozilla.org/catalog/web-developer/examples/kitchensink.xml is now http://www.mozilla.org/docs/web-developer/examples/kitchensink.xml (see bug 193076 comment 5)

Neither of those links work.

http://www.mozilla.org/docs/web-developer/samples/kitchensink.xml sorry

Hey, Excel has a frakin' flight simulator built into the shyte -- Damn it!!! Mozilla needs a kitchen sink.....

Mozilla is downloaded, so any easter eggs would have to be held on the m.o server.

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

about:kitchensink does not work for me. Was the it removed? I'm on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007

It was never included, and probably won't be. http://www.mozilla.org/docs/web-developer/samples/kitchensink.xml

Bug 234710 is about issues with how some links on the web are now invalidated by it being moved from samples to examples, so some links point to examples, some links point to samples. It also talks about other things.

(In reply to comment #152) > It was never included, and probably won't be. > > http://www.mozilla.org/docs/web-developer/samples/kitchensink.xml Any reason for that? :-)

(In reply to comment #152) > It was never included, and probably won't be. > > http://www.mozilla.org/docs/web-developer/samples/kitchensink.xml Yes, though if you bookmark that URL and use the keyword about:kitchensink you can add it in yourself. :) I just tried it in Firefox RC2, worked like a charm. :)

(In reply to comment #6) > A kitchen sink. I'm working on creating it's own about: so everyone can see > that Mozilla is the only app that has everying AND the kitchen sink Sorry, <a href="http://www.nethack.org">nethack</a> got there a long time ago.

(In reply to comment #156) > (In reply to comment #6) > > A kitchen sink. I'm working on creating it's own about: so everyone can see > > that Mozilla is the only app that has everying AND the kitchen sink > > Sorry, <a href="http://www.nethack.org">nethack</a> got there a long time ago. But, this one is very cool! Good job folks. Is it intentional that it doesn't work in IE?

This is still WONTFIX.

(In reply to comment #158) > This is still WONTFIX. After separating Mozilla Suite (or whichever name it has now) and Firefox, the component field is perhaps really wrong, but I would keep the bug open for Application Suite (philosophy of which is still to have all features, /including/ a kitchen sink).

For me, the kitchen sink doesn't work if you have the Linkification extension enabled. My guess would be a string with a combonation of letters, @, and . somewhere, and it seems to cause a loop in either the kitchen sink script or the Linkification script.

Those Konqueror lamerz don't support Mozilla's kitchen sink. :) Nevertheless, I think there is always room for improvement. If it is turned on for some time, it could fill up with water and when turned off, display a vortex as the water goes down the drain...

and have the vortex go a different way depending on locale...? :)

Is it just me, or does the kitchen sink pour out PoOp out of the faucet? Is the new motto going to be "And it has a kitchen sink too, but it just smells bad"

There have been a ton of comments on this bug, but comments 119 and 120 sum up nicely why this never got checked in. I'd suggest if any particular product wants the kitchen sink (SM council for suite directory?), a new bug be filed for that purpose.

Per bug 392565 comment 1, comment 164 should be disregarded with regards to Seamonkey. This bug is about seamonkey. Please do not make dupes of this bug due to comment 164. Thanks.