Closed Bug 122411 (kitchensink) Opened 19 years ago Closed 15 years ago

Mozilla does not have a kitchen sink

Categories

(www.mozilla.org :: General, enhancement, P5)

enhancement

Tracking

(Not tracked)

VERIFIED WONTFIX

People

(Reporter: grey, Assigned: grey)

References

()

Details

(Whiteboard: see comments 119, 120 for why this didn't get checked in)

Attachments

(3 files, 17 obsolete files)

20.24 KB, application/xhtml+xml
Details
1.04 KB, patch
Details | Diff | Splinter Review
987 bytes, patch
Details | Diff | Splinter Review
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.
Assignee: asa → jesusx
I have enough bugspam to last me years
QA Contact: doronr → jesusx
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 ;-)
Severity: enhancement → major
Status: UNCONFIRMED → NEW
Component: Browser-General → Cookies
Ever confirmed: true
OS: Windows 98 → other
Hardware: All → Other
Whiteboard: (home navigation transport protocol)
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. ;-)
Attached file A kitchen sink. (obsolete) —
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.
Severity: major → enhancement
Status: NEW → ASSIGNED
Component: Cookies → Networking
OS: other → All
Priority: -- → P2
Hardware: Other → All
Target Milestone: --- → mozilla0.9.9
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.
Attachment #67056 - Flags: needs-work+
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 :-)
Attached file A Kitchen Sink With Running Water (obsolete) —
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.
Attachment #72037 - Flags: needs-work+
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.
Attached file Another try (obsolete) —
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...
Attached file This validates w3c XHTML 1.1 (obsolete) —
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
Attached file Speedup (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?
Attached file XHTML 1.1 Version of Attachment 72289 (obsolete) —
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 ?
Keywords: mozilla1.0
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">'.
Attached file Validates - all others obsolete (obsolete) —
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.
Attached file Final version of sink (obsolete) —
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
Attachment #67056 - Attachment is obsolete: true
Attachment #72037 - Attachment is obsolete: true
Attachment #72040 - Attachment is obsolete: true
Attachment #72041 - Attachment is obsolete: true
Attachment #72057 - Attachment is obsolete: true
Attachment #72206 - Attachment is obsolete: true
Attachment #72289 - Attachment is obsolete: true
Attachment #72301 - Attachment is obsolete: true
Attachment #75745 - Attachment is obsolete: true
Attachment #76401 - Attachment is obsolete: true
Comment on attachment 76401 [details]
Validates - all others obsolete

r=gerv. ;-)

Gerv
Attachment #76401 - Flags: review+
Since 0.9.9 and 1.0 are out the door...
Target Milestone: mozilla0.9.9 → mozilla1.0.1
Comment on attachment 76401 [details]
Validates - all others obsolete

fixing which patch has r=
Attachment #76401 - Flags: review+
Attachment #86945 - Flags: review+
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?
Alias: kitchensink
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.


QA Contact: jesus_x → benc
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...
Summary: Mozilla does not have a kitchen sink. → Mozilla does not have a kitchen sink. (about:kitchensink)
Whiteboard: (home navigation transport protocol)
(left).

Someone should get practice for a good job, and take QA of this.
Keywords: qawanted
QA Contact: benc → nobody
Summary: Mozilla does not have a kitchen sink. (about:kitchensink) → about:kitchensink Mozilla does not have a kitchen sink
 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.
Attachment #86945 - Flags: review+ → review-
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)
Flags: blocking1.3b?
willseatery@yahoo.com, please don't waste peoples' time nominating non-bugs like
this. Thanks.
Flags: blocking1.3b? → blocking1.3b-
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?
Attachment #86945 - Attachment is obsolete: true
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.
Attached file Latest copy, not finished (obsolete) —
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. :-)
Attachment #113787 - Attachment is obsolete: true
Has a nice little DEMO of how to work it. This is it.Hope you like it :-)
Attachment #114123 - Attachment is obsolete: true
BTW: NS 7.01 doesn't display the shading behind the handle. You need to use it
in a newer browser.
Attached file !!!FINAL!!! version :-) (obsolete) —
Bah, _some_ people are _so_ picky ;-)
Attachment #114188 - Attachment is obsolete: true
"!!!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...
Attachment #114190 - Attachment is obsolete: true
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.
Attachment #114921 - Flags: superreview?(darin)
Attachment #114921 - Flags: review?(dougt)
Comment on attachment 114921 [details] [diff] [review]
Patch to enable about:kitchensink

r=dougt  very funny.
Attachment #114921 - Flags: review?(dougt) → review+
Attachment #114922 - Flags: superreview?
Attachment #114922 - Flags: review?(dougt)
Attachment #114922 - Flags: superreview? → superreview?(darin)
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.
Attachment #114921 - Flags: superreview?(darin) → superreview+
changing target milestone so it's no longer in the past.
Target Milestone: mozilla1.0.1 → mozilla1.4alpha
Attachment #114922 - Flags: review?(dougt) → review+
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 =)
Attachment #114922 - Flags: superreview?(darin) → superreview+
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?
Attachment #114921 - Attachment is obsolete: true
Attachment #114922 - Attachment is obsolete: true
Comment on attachment 114985 [details] [diff] [review]
Revised first patch

Carrying over r= from dougt and sr= from darin
Attachment #114985 - Flags: superreview+
Attachment #114985 - Flags: review+
Comment on attachment 114986 [details] [diff] [review]
Revised second patch

Carrying over r= from dougt and sr= from darin
Attachment #114986 - Flags: superreview+
Attachment #114986 - Flags: review+
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.
Attachment #114986 - Flags: superreview-
Attachment #114986 - Flags: superreview+
Attachment #114986 - Flags: review-
Attachment #114986 - Flags: review+
Comment on attachment 114985 [details] [diff] [review]
Revised first patch

agreed
Attachment #114985 - Flags: superreview+ → superreview-
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.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → WONTFIX
Not your bug, kthx.
Status: RESOLVED → REOPENED
Priority: P2 → P5
Resolution: WONTFIX → ---
Target Milestone: mozilla1.4alpha → Future
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.
Summary: about:kitchensink Mozilla does not have a kitchen sink → Kitchen sink example for Mozilla.org standards examples.
>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.
Summary: Kitchen sink example for Mozilla.org standards examples. → mozilla has everything, but the kitchen sink. example demonstration of moz & standards
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.
Summary: mozilla has everything, but the kitchen sink. example demonstration of moz & standards → Mozilla does not have a kitchen sink
Blocks: 196282
Blocks: majorbugs
Moving -> mozilla.org
Component: Networking → webmaster@mozilla.org
Product: Browser → mozilla.org
Version: Trunk → other
Target Milestone: Future → ---
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
Neither of those links work.
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. ***
QA Contact: nobody → stolenclover
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
Status: REOPENED → ASSIGNED
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?
No longer blocks: majorbugs
This is still WONTFIX.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago15 years ago
Resolution: --- → 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.
Status: RESOLVED → VERIFIED
Whiteboard: see comments 119, 120 for why this didn't get checked in
Duplicate of this bug: 392565
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.
Product: mozilla.org → Websites
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
You need to log in before you can comment on or make changes to this bug.