Full Article Attached Independent Project Status Reports

Tuesday May 1st, 2001

Sorry I haven't posted these for a couple weeks, I've been a bit busy. Anyways, here are the status reports I've collected over the last couple weeks. Featured are: Jabberzilla, Beonex, Bookie, mozCalc, Chameleon, mozmp, and XULMaker. Enjoy!

#1 Independent Project Status Reports - RBase Project

by KaiRo

Tuesday May 1st, 2001 11:34 AM

A full status report of RBase will follow when Tony posts the next reports, I sent the mail juast now - unfortunately a bit late for this one :(

Nevertheless, a lot has happened in that project, we made the big step from absolutely zero to something now:

We have a roadmap or task list, and we have some basic code - which doesn't do anything than providing a sample window that's hooked into tasks menu, but still it's something.

Look at for more info or wait for the next status reports :)

#2 fix for bug 76495

by Brendon

Thursday May 3rd, 2001 8:55 AM

> Even more exciting is the fix for 76495 - don't tear down the world before having anything to replace it

wow, thats one nice fix which is really worth checking out the nightlies for. though it does remind me a little of netscape 4.x because of the (reasonably) long pauses which half the time are an indication of netscape crashing. which ofcourse is not the case with mozilla.. well, most of the time :)

nonetheless, pretty neat 'specially if accompanied with 'column by column' rendering, ahem ;)

#3 Re: fix for bug 76495

by gwalla

Thursday May 3rd, 2001 12:07 PM

> nonetheless, pretty neat 'specially if accompanied with 'column by column' rendering, ahem ;)

You mean row by row? HTML isn't column-oriented.

#4 Re: Re: fix for bug 76495

by gerbilpower

Thursday May 3rd, 2001 12:12 PM

I think me means column by column, I have used IE enough to observe that it sometimes renders tables column by column.

Incremental reflow can get a little bit messy while still rendering incomplete pages just before they are fully downloaded, so I'm not sure what exactly is the "best" route here.


#5 Re: Re: Re: fix for bug 76495

by gerbilpower

Thursday May 3rd, 2001 12:24 PM

Actually, nevermind, I think row-by-row would work much better than column-by-column. Because of the way tables are structured in actual HTML, to render column by column would required that the entire table be downloaded first, which pretty much defeats the point of incremental reflow of "rendering as you go."


#6 Re: fix for bug 76495

by Brendon

Thursday May 3rd, 2001 12:34 PM

lol, okay.. i've managed to confuse myself again.. obviously i meant row by row.

currently mozilla seems to do a rather poor job in displaying pages with large tables before the entire page is downloaded, which with past releases wasnt the case if i recall correctly. i hope it'll be worked on for the next (after 0.9) release.

speaking of releases, how are we doing with 0.9?

#7 Down the road to 0.9 ...

by gerbilpower

Thursday May 3rd, 2001 1:32 PM

From a newsgroup posting, almost all the bugs designated as needed for 0.9 has been fixed. They are going to create and test more builds and see if there aren't any unpleasant surprises or regressions before releasing it. So TENTATIVELY speaking, we might see it in a day or two.


#9 great..

by Brendon

Thursday May 3rd, 2001 1:40 PM

..not that i'll ever use it ;) its great to see how mozilla improves by just using the nightlies..

Bren, who should really stop littering these talkbacks :)

#8 I guess what you're seeing is cell by cell...

by bim

Thursday May 3rd, 2001 1:37 PM

I guess what you see is cell by cell. It only looks like column by column. A lot of sites have one big table with two or three cells in one high row. Because it's so high, and there's only one cell in a column, it looks like "column by column" rendering. When, for example, I go to I see the three columns (cells) rendered one by one.


#10 hmm..

by Brendon

Thursday May 3rd, 2001 2:50 PM

whatever the case, mozilla doesnt do well compaired to other browsers in this aspect.

opera: renders your link cell by cell, everything appears in the place where it will stay when the page has been fully loaded

konqueror: does the same as opera however it seems to display things far sooner than other opera and causes the tables to be misplaced at first and will be moved as the other cells are showed. (this can be very annoying on slow computers and is perhaps worse than netscape 4.x's behavior because it takes more cycles)

netscape: is unresponsive till the entire page is loaded. (often this is when netscape will crash *sigh*)

mozilla: is unresponsive till the entire page is loaded.

'nuff said :)

#11 Re: hmm..

by WillyWonka

Thursday May 3rd, 2001 8:27 PM

I believe I read somewhere (Probably one of those performance mails which are posted to n.p.m.performance) that mozilla waits 1.2 seconds and then starts displaying incrementally. If you have a cable modem or ADSL, a lot of pages download before that 1.2 seconds and they display. On a 14.4 I'm sure you'll see the incremental updates.

In any case, they are still trying to find a happy medium between percieved speed and actual speed.

#12 foo

by Sparkster

Friday May 4th, 2001 2:28 AM

Yes, I noticed too, that Mozilla waits for a short time and then starts to show new content. I wonder, why is it so? Can't it be avoided? But I agree, Gecko rendering feels quite fast overall. Just not when watching incremental load. :)

#13 bug 51202

by Brendon

Friday May 4th, 2001 5:06 AM

i think this covers the problem

#19 Re: bug 51202

by SubtleRebel

Friday May 4th, 2001 7:12 PM

Sometimes after reading a bug report, I am not sure what it is about, but I think Matthew did an excellent job of outlining the issue and proposing an idea for a fix. I wish I had some time to help work on this. It sounds like it could result in a very nice balance of performance of incremental and total load/render time.

#14 Re: foo

by fab

Friday May 4th, 2001 5:33 AM

1) We wait until we have something to display (this is brand new) 2) After an initial paint, the painting is locked for a defined time (1.2s?) to avoid too many reflows that hurt performance. (this went in right after 0.9 branched) So what you are seeing is as designed, and a huge performance gain. As for the tables I'm not sure, I've never had any problem rendering them

#15 themes wont install?

by Brendon

Friday May 4th, 2001 1:15 PM

I\'ve had this problem for a week now i think. not sure if its confined to my comp so is anyone else having the same problem?

All dialogs appear as they'd usually do, however the 'install progress'-dialog closes rather quickly. after which i concluded it might have been a permissions problem though running mozilla as root doesnt help.. so, i'm lost..

#16 Re: themes wont install?

by stfh

Friday May 4th, 2001 4:28 PM

What theme(s) are you trying to install?

Recently Moz has switched to a new more secure install method for themes, and the theme authors have to switch to the new method or the install will fail.

Try the graymodern theme at as a testcase; I know that one has been updated.


#17 Re: themes wont install?

by Brendon

Friday May 4th, 2001 5:06 PM

no luck.. either running as a normal user or root. all dialogs appear and the 'download/install progress meter' shows:

connecting to

transering from

after which the dialog disappears, without downloading the theme.

using the latest nightly, shouldnt be a problem there though, nor with permissions so i was guessing it had something to do with the chrome install path (running debian sid with mozilla installed and mozilla nightlies sometimes causes the nighly to use the packaged mozillas shared directories), though that wouldnt explain why the theme install exits before anything is downloaded..

#18 Re: Re: themes wont install?

by Brendon

Friday May 4th, 2001 5:07 PM

err, transfering.. before Alex starts having a go at me again :)

#20 Re: Re: Re: themes wont install?

by AlexBishop

Saturday May 5th, 2001 7:48 AM

" err, transfering.. before Alex starts having a go at me again :)"

Actually, it's 'transferring'. ;-)

Alex (visit Newzilla now. It's great. And nothing to do with me.)

#21 Re: Re: Re: Re: themes wont install?

by Brendon

Saturday May 5th, 2001 8:30 AM

heh, oh well..

#22 newsgroups

by macpeep

Sunday May 6th, 2001 2:58 AM

We really need a "general discussion and questions" area here because there are lots of general questions that just don't fit in with stories / articles.. Anyway..

Wasn't there some plan to move the newsgroups and rename them? What's the status on that project lately?

Also, completely unrelated, the screenshot section really needs to be updated. The latest screenshots are of blue, and we've had a whole Modern theme inbetween (and a lot of development) that has gone by undocumented. It's not like all of us here don't know what Mozilla looks like, but for documenting the progress, it would be nice to have pics of older versions. Just take a look at the older pics and you'll know what I mean.

#27 Re: newsgroups

by broken

Sunday May 6th, 2001 3:01 PM

I've been thinking about this myself for some time... Conversation tends to become off topic very often, because we start discussing whatever the latest topic is but we end up talking about many other things about Mozilla.

All: would you be interested in having a Mozilla forum at We could have folders such as "general discussion", "latest builds", "bugs", things like that. I like Delphi's format myself, but something else like an UBB board would be good as well.


#33 Re: newsgroups

by afranke

Monday May 7th, 2001 1:06 AM

The latest update on the newsgroup reorg is from May 4th saying it "depends on SIR #21491 (opened 03/21/01) being completed", whatever that is.

The new newsgroups structure can still be found at

There is a tracking bug for this in Bugzilla.

#23 NeoPlanet dumps Mozilla?

by macpeep

Sunday May 6th, 2001 4:29 AM

What's this I hear about NeoPlanet having dumped Mozilla in favor of IE recently? I can't find anything on NeoPlanet's site about this, but that's not exactly surprising. Does anyone have more information? Also, why wasn't this reported on MozillaZone - it's pretty major (though bad) news for Mozilla. Surely MozillaZine doesn't just report positive Mozilla news!

#24 Re: NeoPlanet dumps Mozilla?

by Brendon

Sunday May 6th, 2001 5:31 AM

Apparently they made an announcement in which was said that they have temporarily canceled their work on embedding mozilla.. or something along those lines.

my guess (and that of many others judging by the talkbacks on, 'fraid i couldnt find the article again though) is that we wont be seeing neoplanet release a browser with gecko for a long time, probably only if mozilla gains popularity.

#25 Re: NeoPlanet dumps Mozilla?

by Brendon

Sunday May 6th, 2001 6:43 AM

"NeoPlanet Postpones Mozilla Work, Expands Beyond Browser Paradigm"

#30 Re: NeoPlanet dumps Mozilla?

by basic

Sunday May 6th, 2001 9:27 PM

I had doubts about NeoPlanet's "commitment" to Mozilla for sometime. They seem to have lots of announcements lately but I've not seen a product based on Mozilla or any contribution to

#26 Nightly kills personal toolbar bookmarks

by Brendon

Sunday May 6th, 2001 9:29 AM

the title says it all really, so if you dont have a backup (which i cant imagine if you re using nightly builds.. but just incase) make one before you use the currently nightly. after importing your old bookmarks they 'll not be deleted.

also the current build has new icons for navigator, looks a little odd.. but as usual its an improvement.

#28 Re: Nightly kills personal toolbar bookmarks

by SmileyBen

Sunday May 6th, 2001 5:26 PM

OOOH! Can we have a screenshot?

#29 screenshot..

by Brendon

Sunday May 6th, 2001 5:46 PM

#31 Better for sure

by tono

Sunday May 6th, 2001 10:32 PM

The new back forward etc. buttons look much better than the old ones. I just can't help but think there's a better way though. Still has the old throbber though, and I'm a big fan of those artistic mockups of a big wheel thing.

#32 better but...

by macpeep

Monday May 7th, 2001 12:20 AM

Actually, it's not just better. It's very nice! But.. It's inconsistent with the rest of the app and even the print button looks different. All other toolbars has an icon in the left edge and a whole different style, different sized throbber etc. The inconsistency is not a good thing. :/

#35 Re: better but...

by saberunit02

Monday May 7th, 2001 7:45 AM

My first impressions: It looks better than the previous iteration, but it also could be better. I prefer the last printer icon to the new one. The borders around the navigation buttons that appears when clicked should go. While the globe icon in composer is consistent with the envelope design in mail, it is not as clean as the envelope.

#36 Re: Re: better but...

by tny

Monday May 7th, 2001 1:42 PM

Maybe a printing press for Composer, and a globe (without the tag names) for Navigator?

#34 Ooooh!

by SmileyBen

Monday May 7th, 2001 5:52 AM

Those are actually gorgeous! I like!