previous status updates

by Chris Nelson <chrisn@statecollege.com>

Last Updated Saturday, November 7th, 1998

Module Updates
MacFE
October 30th
Submitted by Mike Pinkerton <pinkerton@netscape.com>

Mike Pinkerton writes in with this update: "Trying to get up to speed on NGLayout and (ugh) COM. Fixing bugs in mac viewer and trying to make mac nglayout not suck."

 

XFE
October 30th
Submitted by Chris McAfee <mcafee@netscape.com>, Ramiro Estrugo <ramiro@netscape.com>

Chris McAfee writes:

XFE/Unix team is wrestling with the following issues:

  • Moving main Unix development from Motif to GTK; - AWT? - L10n/i18n?
  • We're trying to get webshell/tests/viewer/main up and running on more than just Linux
  • The build system is underwater right now, and needs a lot of help. Some people think now would be a good time to get autoconf working.

Ramiro Estrugo writes:

  • Started to work of gtk stuff.
  • Mike Shaver checked in some gtk gfx code.
  • Currently working on makefile and directory naming logistics.
  • NGLayout viewer builds and runs on linux
  • XPviewer coming soon
Composer
October 30th
Submitted by Akkana Peck <akkana@netscape.com>

Akkana Peck writes, "The Composer team is in design meetings, figuring out what work needs to be done to make a fully-fledged Composer in the NGLayout world. We will post our preliminary design documents for public comment, when they're ready (in a few weeks)."

 

ImgLib (Image Library)
October 30th
Submitted by Pam Nunn <pnunn@netscape.com>

Pam Nunn writes in with this update:

Image Lib, while used in NGLayout branch, does not take advantage of all the new goodies. I'm focusing on changing the interface to PNG, so we can have some true alpha channel support via access to the new compositer. I'm betting many functions can be radically simplified.

Several patches have been submitted that are on hold until the build environment is stable.

 
NGLayout
October 30th
Submitted by Troy Chevalier <troy@netscape.com>

Troy writes:

  • more work on table incremental reflow
  • scroll frame is not being used for scrolling of the BODY element
  • changes to the way floaters are handled. Rather than being moved out as children of the BODY they're kept in their containing block frame
JavaScript/Java Reflection
October 30th
Submitted by Scott Furman<fur@netscape.com>

Development continues on the JavaScript development branch (CVS tag: SpiderMonkey140_BRANCH).  We are hoping to land a stable snapshot of this branch on the trunk early next week.

  • The group is continuing to focus on stability, running language tests on many platforms including Mac, Windows 95/98/NT, HP/UX, AIX, Solaris, DEC OSF, IRIX and x86 Linux and fixing dozens of bugs.  A few bug-fix highlights: Bjorn checked in a fix that should unbusticate JavaScript on some 64-bit platforms, including Alpha Linux.  Norris fixed another heinous 64-bit bug that was inflicting pain on Dec OSF.  There are now only a handful of known bugs in the JS engine.
  • Along with bug-fixing, the whole group conducted a compiler-warning exorcism.  We're now warning-free on all but a couple of platforms.
  • Scott checked in the remaing work on LiveConnect version 3 features.

See all the recent check-ins to JavaScript.

Builds / Build Config
October 30th
Submitted by Christopher Yeh <cyeh@netscape.com>

Chris writes:

On Monday, everyone who needs the old code (referred to hereafter as MozillaClassic) to finish feature work will be on a seperate code branch.

On Tuesday, Raptor and "the new thing that will be Mozilla 5.0" will own the tip of the mozilla source tree. So on Tuesday I will be landing the XPCOM_BRANCH in mozilla/modules/libpref into the main trunk, simplifying the source pulls.

Module Updates
NGLayout
October 25th
Submitted by Troy Chevalier <troy@netscape.com>

Tables:

First cut at incremental table layout is done.  We can append/insert/remove captions, colgroups, columns, rowgroups, rows, and cells.  Not yet 100% optimized, but pretty efficient.  Still some work to do to ensure that internal table state is always consistent.

General:

  • Support for "font-variant: small-caps" went in.
  • Support for "text-transform: lowercase|uppercase|capitalize" went in.
  • Several bugs having to do with PRE formatted text were nailed.
  • "Reduce memory footprint for text content" (50% typically) went in.
JavaScript/Java Reflection
October 25th
Submitted by Scott Furman<fur@netscape.com>

JavaScript development continues on SpiderMonkey140_BRANCH.  We hope to drop a stable release of this branch onto the tip in the first week of November.

  • We spent this week doing lots of multi-platform testing and bug-fixing, particularly platform-specific bugs and build problems on unix platforms such as AIX, HP/UX, and OSF1.  In order to fix inadequacies in some vendor-supplied math libraries (with are the basis for the JavaScript Math object), Mike Ang added fdlibm, a library which either wraps the vendor-supplied functions or re-implements them correctly.

  • Scott Furman altered the build so that certain platform-specific parameters (stored in the jscpucfg.h file) are automatically generated rather than relying on developers to manually make changes to this file for every platform.  Hopefully, this will cut down on the platform-specific patches to JavaScript.

See all the recent check-ins to the JavaScript interpreter.

 

Builds / Build Config
October 25th
Submitted by Christopher Yeh <cyeh@netscape.com>, Brian Ostrom <briano@netscape.com>

Chris writes:

  • Removed -DNSPR20 from code. Just say no to useless #ifdefs.

Brian writes:

  • The exciting news (zzzzzz...) in build/config is the new, simplified include path mechanism. No longer do we see dozens of -I$(XPDIST)/public/blahblah flags in each compile command on UNIX. Now, in general, headers go in dist/include. The first rebuild needs to be from the top, so all the headers get exported into dist/include, but other than that there should be no difference. Just less crap scrolling past.
LDAP
October 25th
Submitted by Chuck Boatwright <chuckb@netscape.com>

Chuck writes, "The ldap sdk for C has been completely updated. Currently, all of the work is being done on a branch, LDAPCSDK_19981015_BRANCH.

This branch has more 100 bug fixes, and several new features.

The merge to the trunk should be in a couple days, new tar files will be produced once this happens. Any questions on this work should be sent to

mozilla-directory@mozilla.org

or to the newsgroup

netscape.public.mozilla.directory

 

Module Updates
WinFE
October 16th
Submitted by Bill Law <law@netscape.com>
  • Bill Law spent most of the week tackling Mozilla P1 bugs. His list is now down to 1!
  • Garrett Blythe is back from sabbatical! Actually, he's been back for a couple of weeks, I just forgot to mention it. He's working 5.0 bugs, too.
  • Dan Matejka completed some features for 5.0, including wiring in the show/hide toolbar menus to the new chrome. He also worked on bugs.
  • David Hyatt has been out sick most of the week. Send him get-well wishes at hyatt@netscape.com.

 
MacFE
October 16th
Submitted by Steve Dagley <sdagley@netscape.com>

Steve Dagley writes in with this update:

  • Improved drawing code for new toolbars to reduce flicker.
  • Improved realloc code for small block allocation.
  • Prep work for NuCache (should land next week).
XFE
October 16th
Submitted by Ramiro Estrugo <ramiro@netscape.com>

Ramiro Estrugo has this update for us:

ramiro:

  • URL bar back in business.
  • Navigation buttons back in business.
  • Working on XP code to do dynamic menus.
  • Random bug fixes.

slamm:

  • Column sorting / resizing Toolbar context menus.
  • Toolbar sensitivity.
  • Random bug fixes.

radha:

  • Some custom icon/colors work.
  • Selector bar back in business (#ifdef MOZ_SELECTOR_BAR)

mcafee:

  • More smartmail work. I think its useable now.
  • Rhapsody hacking
NSPR (Netscape Portable Runtime)
October 16th
Submitted by Srinivas Lingutla <srinivas@netscape.com>

Srinivas writes:

  • Source patches for version 3.0 of nspr are checked in.
  • Presentation on "Combining Apache with Netscape's NSPR" by Dean Gaudet at Apache Con 98 on Oct 16, 1998. ApacheCon '98: Agenda

 
GTK/GnomeFE port
October 16th
Submitted by Chris Blizzard <blizzard@appliedtheory.com>

Chris Blizzard writes, "Michael O'Reilly and Frank Visser have been working hard and there has been some progress. Fonts are working and pages look a lot better. Images are mostly rendering although there are still problems with transparent images we're still trying to nail down. Have a look at the updated screen shot."

 
Current Layout
October 16th
Submitted by Mike Shaver <shaver@netscape>, Nisheeth Ranjan <nisheeth@netscape.com>

Mike Shaver writes, "Perignon: more architectural work in place, now working on additional attribute support."

What's "Perignon"? Read on...

From Nisheeth Ranjan, we get this update:

Layout:

  • Mike Shaver and Eric Pollmann are working on Perignon. This is a project that tries to store CSS style information on a tree rather than in a style database consisting of hash tables keyed on tags, classes, and ids. They have already gotten CSS inheritance to work much better with this approach. Read about it at http://www.mozilla.org/layout/perignon.html.
  • Layout Probe API. We are pretty close to completing an API that will let an external DLL query layout for information about the different layout elements displayed on screen. The second code drop from Ori Kravitz was checked in today. All that remains is to do traversal of layers and implement a function on each FE that listens for an external process's request for loading the test DLL.
  • Layer/Ilayer reflow got checked into mozilla this week. This should fix layout on sites like slashdot.org and altavista which display banner ads inside ilayers.
  • Mariner bug fixing is going on as usual. The scrollbar no longer jumps up and down as you resize the window. Adjacent left aligned tables do not swap places on resizes.
  • An experimental change went into Mozilla this week where we enable the compositor at the end of layout rather than at the beginning. This essentially keeps the earlier page on the display until enough of the next page is available for display, and then, boom, the new page displays. Blank page time is reduced a lot. We need to discuss with all the mozillians out there which of the following two options they like better:
    • a) clicking a link and seeing a blank page for 10 seconds before the new page displays.
    • b) clicking a link and seeing the new page's layout progress on the status bar for 10 seconds before the new page displays.

    If anybody reading this status report has feedback on this issue please post to the mozilla.general newsgroup.

Mariner (page reflow) To Do List:

  • Apply CSS style rules during reflow.
  • Implement timeout based reflow so that resizes on large pages return to the event loop and don't hang the UI.

NGLayout
October 16th
Submitted by Troy Chevalier <troy@netscape.com>

The big NGLayout items we'll be working on for the next few weeks include:

  • table incremental reflow
  • implementing the scroll frame formatting object. This will allow us to support the CSS overflow:scroll property
  • getting print preview working again. Once print preview (and page-mode) are working again we'll add support for printing

Some bug fixing over the past week includes:

  • better handling of the vertical-align property
  • better handling of the clear and float properties

 

HTML Dialogs
October 16th
Submitted by Nisheeth Ranjan <nisheeth@netscape.com>

Nisheeth writes, "The localization folk are working on making changes to HTML dialogs that will make them very simple to localize. Contact Rick Elliot <relliot@netscape.com> for more information.

Composer
October 16th
Submitted by Akkana Peck <akkana@netscape.com>

Akkana Peck writes in with this Composer module update: "Ender multipart mime code has been checked in, under the ifdef MOZ_ENDER_MIME. Development continues on Ender and its associated mime routines.

In other parts of Composer, bug fixing continues; in particular, we're working on getting table editing more solid and in changes to the publishing procedure to work with the single signon system."

 
Mail Compose
October 16th
Submitted by Akkana Peck <akkana@netscape.com>

Akkana Peck also has this update on the Mail Compose module: "SmartMail has been enabled by default in the builds. In the XFE, the MOZ_MAIL_COMPOSE AddressOutliner is the only class remaining which still uses the Outliner.cpp class. If the addressing area were rewritten, we could get rid of this class. Anyone interested in taking this on, writing an addressing system which uses shack widgets?"

 
Libpref
October 16th
Submitted by Edwin Aoki <aoki@netscape.com>

Edwin has this update for us: " Over in libpref land we're beginning the process of putting the XPCOM interfaces into libpref, and porting the profile manager changes that went into 4.5 to the Mozilla codebase. You probably won't hear a lot from us for the next week or two, but your opinions on what we did right -- and wrong -- in 4.5 are always useful and welcome."

Libmocha (JS-only DOM level 0)
October 16th
Submitted by Mike McCool <mlm@netscape.com>

Mike writes, "Progress continues on libmocha; Steve Morse is using the multithreaded libmocha to do HTML permission dialogs, and there are bugs to be worked out there. Soon the 4.x bug merges will begin filtering in as well. I'm also doing work on stopping memory leakage in libmocha, which has been pervasive for far too long."

JavaScript/Java Reflection
October 16th
Submitted by Scott Furman<fur@netscape.com>

After two weeks of drum rolls, we've finally landed the merged JavaScript ref/src code.  We're continuing primary development on the SpiderMonkey140_BRANCH and we'll try to make drops of known-stable JS engine code from the branch to the trunk as often as feasible.

  • mccabe is putting the finishing touches on JavaScript exception support.
  • mang has introduced a very preliminary version of the JavaScript File object, so that JavaScript can access files without using LiveConnect.  (This won't be compiled into mozilla, but you can build it into the standalone JS engine as an option.)
  • coop has implemented propagation of JavaScript exceptions into Java and vice-versa for LiveConnect.
  • fur has implemented improved method overload resolution for LiveConnect.
See all the recent checkins to the JavaScript engine and LiveConnect on the SpiderMonkey140_BRANCH.

-Scott

 
Berkeley DB 2
October 16th
Submitted by Frederick Roeber <roeber@netscape.com>

Frederick Roeber writes in with an update on the status of the Berkeley DB module.

"The initial CVS import of Berkeley DB 2.4.14.1 from Sleepycat was done Wednesday evening. The repository directory is mozilla/db; though no module pulls it yet, it's there. It's been imported on the vendor branch; vendor tag SLEEPYCAT, release tag DB_2_4_14_1. Technically Sleepycat is module owner, but since they're still getting their CVS access going, I did the import for them.

The next step will be integrating it with the build. I'd like to set it up so that one can either use an already-compiled version, or (if this is wanted) pull and build it as part of the mozilla build.

After that, the mozilla-specific code (hooking in NSPR underneath, doing the initialisation, etc.) will be added elsewhere, probably mozilla/modules/db. I'll probably end up module owner of that for now."

Builds / Build Config
October 16th
Submitted by Christopher Yeh <cyeh@netscape.com>

Chris writes:

  • Removed requirement of having to setenv NO_SECURITY when building Mozilla.
  • Removed -DNSPR from define line. The #ifdefs had decayed beyond usability, and it's not like we could ever build Mozilla without NSPR again
Module Updates
OJI (Open JVM Integration)
October 10th
Submitted by Warren Harris <warren@netscape.com>

Warren Harris writes in with this lengthy update to the status of Open JVM Integration:

Open JVM Integration (OJI)

General OJI Development
  • Working toward an API freeze for the basic XPCOM plugin functionality. We actually established a deadline to complete the final changes in this area by today (10/9), but a lot of work has fallen on my plate and we probably need to push it out another week. [warren -- his fault] Remaining API changes in store are:
    • Converting over to more NGLayout-like networking APIs (addition of an nsIPluginStreamListener and nsIPluginInputStream).
    • Converting over to the use of nsIServiceManager to manage access to other browser services. This gives us a means to asynchronously notify of service shutdown, facilitating the dynamic unloading of modules.
    • Additional APIs for accessing cookies, preferences, etc.
  • Schedule. The latest OJI schedule shows up finishing up around the beginning of November (modulo my slippage). [warren]
  • Testing. We came up with a long list things that should be tested for OJI -- both Plugin API compliance and JVM compliance. I'll add a link to it later. [warren]
  • Java plugins in NGLayout! Michael has done a substantial portion of the work necessary to make new XPCOM based plugins and JVM plugins work in the NGLayout engine. The LiveConnect code isn't hooked up yet, but it's underway. [michaelp]

LiveConnect (Java/JavaScript integration)

  • Massive progress has been made in the area of LiveConnect integration. All the basic Java/JavaScript interoperability is in place and we're now focused on security issues, allowing privileges to be enabled in JavaScript before calling Java and vice versa. [sudu]
  • Because JNI assumes that "since you're native code, you can do anything" we had to build a SecureJNI mechanism that would allow JavaScript privileges to be propagated into Java. This has panned out to become a JNIEnv proxy object that lives in the browser that talks to an nsISecureJNI object that lives in the JVM plugin. Moreover, this architecture gave us the perfect means to deal with the "same process, different threading worlds" problem that has been lurking in the background for ages. Patrick and Sudu along with Stanley and Ben from JavaSoft co-designed this and got it going. [beard, sudu]
  • In conjunction with the nsISecureJNI interface, we had to implement an nsISecurityContext interface that would manage the privileges that propagate between JavaScript and Java. This is mostly implemented, but not yet exported to the JVM plugins. [sudu]

Java Security Architecture

  • There are two main aspects of security we're dealing with:
    • Privilege enablement. This is the integration of JavaScript privileges with the Java 1.2 security architecture, described above. [sudu]
    • Certificate verification. This allows Java VMs to verify signed JAR files by calling on certificate verification facilities built into the browser. The trick is to do this without invalidating our FIPS 140-1 compliance. Raman has been working with Tom Weinstein to allow Jan at JavaSoft to build a security provider that will do this. [raman]

Apple MRJ JVM Plugin Development

  • The MRJ plugin is coming along nicely and has been delivered to Apple (in conjunction with a corresponding Mozilla browser) for testing. Initially there were several problems on both sides -- Mozilla hitting some assertions due to reference counting problems, and MRJ's AWT having several problems. These are in the process of being ironed out. [beard]
  • Apple is planning a beta of MRJ 2.1 in 2 weeks and would really like to demonstrate the OJI plugin at the same time. [beard]

Microsoft JVM Plugin Development

  • The Microsoft JVM plugin that we worked on earlier this year is still completely on hold. We would love to be able to provide it with Mozilla as an alternative JVM on Windows platform for several reasons:
    • it's already installed on most Windows machines, so download size is kept to a minimum,
    • it's fast, and
    • it's what some people want to use.
    Unfortunately, we have no one to work on it right now, and the code has bit-rotted somewhat as the main OJI development has evolved. Contact me if you want to be a hero and become the owner of a really cool contribution to mozilla.org. [warren]
MacFE
October 9th
Submitted by Steve Dagley <sdagley@netscape.com>

Steve Dagley writes in with this update:

  • First draft of new toolbar code is in. Some things, like editing personal toolbar and drag & drop, are known to be broken so no bug reports on the new toolbar code just yet please.
  • Privacy Tools hierarchal menu now implemented on Mac (under the Window menu).
  • Improvments to the memory allocator code.
Rhapsody Port
October 9th
Submitted by Chris McAfee <mcafee@netscape.com>

Chris writes:

  • I've set up cmd/ybfe/src2 as a copy of the prototype viewer NGLayout demo, doesn't link yet.
  • NGLayout has a cvs module now, so it's slightly-easier to build now.
  • New unix newsgroup: news://news.mozilla.org/netscape.public.mozilla.unix

 

 
GTK port
October 9th
Submitted by Chris Blizzard <blizzard@appliedtheory.com>

Chris Blizzard writes, "I cleaned up a lot of the pixmap rendering code that Michael did originally so it was a bit more sane. Can people take a look at it and see if it works for them? It's a lot less code than it used to be. The Region* code that's in there is very hackish and needs to be cleaned up. I'm still not fully aware of all of the issues involved so I'm going to do some more research on it."

Chris wanted me to mention that Michael O'Reilly <michael@metal.iinet.net.au> had done most of the work on this code, and his work was mostly just cleanup.

NGLayout
October 9th
Submitted by Troy Chevalier <troy@netscape.com>, Rick Gessner <rickg@netscape.com>

Before any of the technical updates, the big news on the NGLayout front is the advent of nightly builds available at ftp.mozilla.org! Go to the binaries section to access all the mozilla.org builds - just be sure to read the warnings!

Rick Gessner has the first of two updates for NGLayout:

  • Considerable CSS1 support improvements.
  • Broader DOM level 1 support
  • DOM control of CSS1 properties (which makes an unbelievably cool demo)
  • Partially incremental tables (more to come in the next 3 weeks)
  • Inline fieldsets
  • Improved plugins and applets
  • First prototype of new XPFE (cross platform front end). Too cool for words!
  • Better "bad html" parsing

Troy Chevalier sent a note with some updates on the work of specific programmers:

Steve is working on table incremental reflow:

Incremental Reflow for nsTableOuterFrame. This supports optimized incremental reflow for these cases:

1. caption inserted

2. caption deleted

3. caption content changed

4. caption alignment changed (top to bottom, bottom to top)

5. inner table content changed

Kipp has been doing various things, including fixing floaters bugs and more top/bottom margin work.

I finished up separating the reflow protocol out of nsIFrame, and now I'm working on reviving the scroll frame code.

Composer
October 9th
Submitted by Akkana Peck <akkana@netscape.com>

Akkana Peck writes in with this Composer module update: " We have been continuing to work primarily on bugs, making Composer more useable, friendly, and better at 'good HTML'. In Windows, we implemented improvements in Publishing (including remembering your username and password as part of the app-wide 'Single Signon' system); this will follow shortly on other platforms."

 
Mail Compose
October 9th
Submitted by Akkana Peck <akkana@netscape.com>

Akkana Peck has this update on the Mail Compose module: "Multipart mime is being rewritten to make it usable by Ender (the embedded composer). We hope to have some demos in a week or two. SmartMail has been turned on by default and is making progress on Unix."

Libmocha (JS-only DOM level 0)
October 9th
Submitted by Mike McCool <mlm@netscape.com>

  • Multithreaded libmocha landed the week before last week - it's in and it seems to work.
  • I was on vacation last week and have had other responsibilities this week. Hopefully with the shipping of 4.5 I'll have more time. I really want to get the 4.x bug fixes into Mozilla and continue fixing other 5.0 bugs.
  • There's a new person in working on libmocha; he's working on reflecting RDF into JavaScript right now, and will probably help to fix bugs as well.

 

JavaScript
October 9th
Submitted by Scott Furman<fur@netscape.com>

Last week I wrote about the numerous changes that we were making to the directory structure of the JavaScript interpreter source. We had planned to "land" these changes on the trunk this week. Our testing indicated that we were not quite stable enough to drop the latest JavaScript engine into mozilla yet. (Our goal is absolutely no regressions!) Look for these changes to appear early in the week of October 12th.

Builds / Build Config
October 9th
Submitted by Sarah Broadwell <sar@netscape.com>, Christopher Yeh <cyeh@netscape.com>

Two updates, one from Sarah Broadwell, and one from Chris Yeh.

Sarah writes, "Chris Yeh deleted a bunch more NSPR20 ifdefs getting closer and closer to having it be unnecessary to have it defined. He did successfully delete the LIBMOCHA ifdefs, so defining that is no longer necessary. (these have both been defined on for at least a year, the were never going to be turn-off-able, so no need to keep them around.)

We had some excitement in gromit land with a NSPR3.0/security incompatibility, but that doesn't appear to have affected mozilla. NSPR30 has been in Mozilla for almost 2 weeks now with no ill effect to Mozilla."

Chris writes, " Removed old MOCHA #ifdefs from the Mozilla tree. For a sense of history, the MOCHA #ifdefs were placed into the client back when Brendan Eich was developing JavaScript over two years ago.

Since the odds of going back to a JavaScript-less browser were somewhere near zero, I took the liberty of cleaning out old unused code.

The same thing is occurring with the NSPR20 and NSPR #ifdefs. I'm in the process of removing all of these from the mozilla tree. They should all be gone in a week or so.

The reason why I'm doing this is to give me something to do in my spare time, and make the build configuration a little easier."

Performance Project
October 9th
Submitted by Chris Waterson <waterson@netscape.com>

From Chris Waterson:

  • "Touched down" progress bar changes (they're still under #ifdef). You can build them on WinFE by defining MOZ_SMOOTH_PROGRESS in your environment. XFE landing this weekend, MacFE being reviewed. They'll come out next week.
  • Profiling. Tracked down two big losers: 30% of startup time attributed to grovelling through the windows registry and parsing file extensions; a test case submitted externally demonstrated some really slow stuff that's killing pages with tons of anchors.

 

Module Updates
WinFE
October 2nd
Submitted by David Hyatt <hyatt@netscape.com>

The big news on the WinFE front is the configurable chrome spec, which was placed on mozilla.org this week. The configurable chrome spec is an impressive feat that I encourage you all to take a look at. You can find a summary of the news at mozillaZine, as well as some screenshots and a sample chrome layout created by Jason Kersey <kerz@en.com>, the MozBin admin.

 
MacFE
October 2nd
Submitted by Mike Pinkerton <pinkerton@netscape.com>

Mike Pinkerton writes in with this update: "On Mac, Pro4 landed across mozilla and NGLayout. We're working feverishly on the configurable toolbars and we hope to land ColorSync in the next week or so."

 
XFE
October 2nd
Submitted by Chris McAfee <mcafee@netscape.com>

Chris McAfee writes:

XFE status:

  • RDF tooltips work
  • RDF toolbars are happier
  • Tree was hosed due to NSPR/JS landing last Friday, it took a few days to figure all that out.

NetLib
October 2nd
Submitted by Gagan Saksena <gagan@netscape.com>

Gagan Saksena writes in with the NetLib update:

"I have been working off late on a new cache (NuCache) architecture that I plan on enabling for the rest of the developers on mozilla next week. This new architecture is modular and allows for dynamic addition of "cache modules" or mini-caches. I will also be publishing out a document that describes in detail the architecture, the changes and the API for using the new cache. There will also be a mini-FAQ on the NuCache. How will it affect users? Well, they should see better performance, there are changes which should make the general performance go up. For example, the older architecture cleaned the cache to make space for a new object when the user would click on a link. In the new architecture, the cache gets cleaned in a background thread and hence the user doesn't see maintenance work on the primary thread. There are other miscellaneous improvements too."

ImgLib (Image Library)
October 2nd
Submitted by Pam Nunn <pnunn@netscape.com>

Pam Nunn writes in with this update:

  • Patch from Adam Moss checked in. libimg/src/scale.cpp. This patch fixes bug with interleaved, transparent images.
  • Continued work on ColorSync branch. Branch needs work for Windows and Unix builds.

QtFE
October 2nd
Submitted by Warwick Allison <warwick@trol.no>

Warwick writes in to say, "The qtfe module should appear real soon now."

 
ActiveX Wrapper
October 2nd
Submitted by Adam Lock <locka@iol.ie>

Adam writes in with this update on the status of the ActiveX wrapper for Mozilla's layout engine, which will allow it to be plugged into situations where IE's ActiveX layout control is currently pluggable.

"Currently it's working quite well, implementing most of the functionality of the IE control. I have outgoing events working as well and have written some test apps in VB and VC++. Due to CVS check in/out problems, the most recent changes are still here:

http://www.iol.ie/~locka/mozilla/mozilla.htm "

NGLayout
October 2nd
Submitted by Troy Chevalier <troy@netscape.com>

Troy Chevalier sent a note with some updates on the work of specific programmers:

Kipp:

  • a few key bug fixes here and there
  • re-working of the margin code to better handle collapsing of vertical margins

Steve:

  • new frame construction code for tables finished
  • layout of tables with colspans improved
  • layout of tables with large captions implemented (caption maxElementSize effects table width)
  • much better backwards compatibility for autowidth tables

Troy:

  • separating generic reflow process out of nsIFrame and into nsIFrameReflow
  • new HTML/CSS specific reflow interface, nsIHTMLReflow. All the HTML/CSS frame classes will implement this new interface, and nsIRunaround and nsIInlineReflow will go away
JavaScript
October 2nd
Submitted by Scott Furman<fur@netscape.com>

A huge JavaScript update from Scott Furman!

We're making some significant changes in the organization of the directories containing the JavaScript engine and the JavaScript code itself. If you're not actually working on the JS engine code, you don't need to do anything new - just download and build mozilla as usual. Let me say that again, a little louder: YOU CAN IGNORE THIS MESSAGE UNLESS YOU WANT TO WORK ON DEVELOPING THE JAVASCRIPT INTERPRETER CODE.

Here's a summary of the changes we're making:

  • The two main JavaScript development directories have been merged into one directory.
  • The single-threaded JavaScript engine is now completely decoupled from the Netscape Portable Runtime (NSPR) code.
  • Primary JavaScript development has moved onto a CVS branch.

We expect to "land" the merged source around October 6th, so you should be prepared to pull new source then.

Merging of js/ref and js/src

For historical reasons, there were two variants of the JavaScript engine code, one in the mozilla/js/ref directory and the other in mozilla/js/src. The code in ref was only used to build the standalone JavaScript engine, aka "JSRef". The code in src, which was automatically generated from ref, was used to build the JS engine in the browser. (Internally, we also use this engine in Netscape server products.) The differences between the ref and src engines were limited to simple changes in the naming of types, functions and header files. (For the curious, the reason that we ended up with two JS directories is that the older ref directory was designed to build with an earlier version of NSPR, whereas the newer src directory was designed to link with NSPR2.)

It had become something of a chore to keep the ref and src directories in sync. There was always someone checking into one directory but not the other. So, we decided to make it possible to build both the standalone JS engine and the browser JS engine from the identical sources. The resulting code now lives in the mozilla/js/src directory. (The mozilla/js/ref directory is no longer needed and will be removed shortly.)

NSPR dependency removed

At the same time that we performed the transformation to merge the JavaScript ref and src directories, we eliminated most of the dependencies that the JS engine had on NSPR. This decision complicated the merge somewhat, but the change allowed us to build a minimal standalone JS engine without sucking in numerous unnecessary libraries and it will also help to shield us from future incompatible NSPR changes. The less fortunate result of this decision is that numerous types, macros and function names had to be changed to avoid colliding with their NSPR counterparts, i.e. to handle the case when NSPR header files and JS header files are mixed. This resulted in large deltas to the source code.

The only remaining dependencies that JS has on NSPR are for threading-related primitives, e.g. PR_Lock(), PR_Unlock(), etc. The single-threaded JS engine has no dependency on NSPR at all.

Primary development of JavaScript engine moves to a branch

Try as we might to avoid it, those of us working on the JavaScript engine sometimes break the mozilla build or introduce insidious regressions in JavaScript behavior. We're at the beginning stages of an ambitious plan to insulate most mozilla developers from the bleeding-edge JavaScript engine changes, but still allow them to be exposed to relatively fresh code.

The basic idea is to isolate primary development on a CVS branch and then periodically "drop" the branch onto the trunk. (See this FAQ if you're not familiar with CVS branches.) The drops will only be done after we develop some degree of confidence in the code, i.e. by doing test builds and by running automated tests on the standalone JS engine.. Initially, we hope to perform drops at least once a week, so the code in the browser will never be more than a week behind the code that's being developed. Our first drop will probably take place around October 6th.

If you aren't going to be working on JavaScript engine development, you don't need to change anything about the way that you check out and build mozilla code. However, if you want to develop with the very latest code, you need to check out the JavaScript development branch:

If you would like to use the JS engine, but only with comparitively stable versions of JavaScript, don't use the development branch; use the trunk version, i.e.

cvs co -A mozilla/js/src

However, if you want to develop with the very latest JS engine, you'll need to check out the JavaScript development branch:

cvs co -rSpiderMonkey140_BRANCH mozilla/js/src

or if you already have a JS tree checked out

cd mozilla/js/src; cvs up -rSpiderMonkey140_BRANCH

(For the curious, SpiderMonkey is the internal code name that we use for the JavaScript engine written in C.)

 

Module Updates
WinFE
September 25th
Submitted by Bill Law <law@netscape.com>, David Hyatt <hyatt@netscape.com>

From Bill Law:

  • "HTML pane" work completed
  • Some bugs fixed.
  • Todos: menu work, toolbar show/hide, mail/news interoperability

From David Hyatt: "Several bugs in Aurora were fixed this week. The HTML pane that can be embedded in Aurora tree views has been fully implemented. Improvements and fixes were also made to the configurable toolbars."

MacFE
September 25th
Submitted by Mike Pinkerton <pinkerton@netscape.com>, Steve Dagley <sdagley@netscape.com>

Mike Pinkerton writes in with this update: "On MacFE we have both mozilla and NGLayout building and running with CodeWarrior Pro4. These changes should land Tuesday.

Kudos go to the MacNGLayout team, as they now have it up and running to the point where it lays out web pages (still problems, but hey, it's coming along fast!) "

Steve Dagley writes, "MacFE conversion to build under CodeWarrior Pro4 almost complete - should land next week."

XFE
September 26th
Submitted by Chris McAfee <mcafee@netscape.com>

Chris McAfee writes:

XFE status:

  • tooltip overhaul
  • rdf toolbars are in good shape, ripping out the old toolbars now
  • non-latin1 PostScript fix checked in from the net
  • new newsgroups: news://news.mozilla.org/netscape.public.mozilla.unix and news://news.mozilla.org/netscape.public.mozilla.unix.checkins
  • new XFE space on mozilla (needs work): http://www.mozilla.org/xfe
  • nspr carpool has broken some linux platforms (today) we're working on this over the weekend a little bit.

QtFE
September 25th
Submitted by Ramiro Estrugo <ramiro@netscape.com>

Ramiro writes in with some good news on the Qt front: "Yes, it's true...Finally, QtMozilla is in the mozilla.org cvs repository. It builds, links and runs. It makes my x server bomb, but thats a minor detail at this point. There are a 'few' problems, mostly because of hacks in the XFE. We can now begin to find XP solutions that work with all 3 unix FEs."

 
Composer
September 25th
Submitted by Akkana Peck <akkana@netscape.com>

Akkana Peck writes in with this Composer module update: "Embedded editors in Unix now have attached toolbars, and some bugs relating to toolbars have been fixed. Mac Ender pretty much works now, and pretty much looks like it's going to look.

We're making progress adding multipart mime handing to embedded composer areas.

Bug fixes in the new table editing continue as we try to make the new functionality more solid; look for lots of bug fixes soon, especially in