You are currently viewing a snapshot of taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to, please file a bug.

status update

maintained by Christopher Blizzard <>

Last Updated Tuesday, January 12, 2000

This status update page is updated every weekend. To get updates and news throughout the week you are invited to check out mozillaZine, a site devoted to Mozilla advocacy.

Previous Updates

Friends of the Tree

  • Asa Dotzler and Alan Jones have helped mail/news QA do some testing on menus and accelerator keys and continue to use the product to find lots of bugs. Also, thanks to Henrik Gemal for using the Account Manager and filing some good bugs on it. -- Lisa Chiang
  • Finally got around to landing Franz Sirl's ( Linux/PPC patches, and Mozilla is up and running on that platform. -- Chris Waterson
Module Updates
Jan 04
Submitted by Peter Trudelle <>
  • David Hyatt and Chris Saari made major improvements to focus and blur, key bindings, and command dispatching for M12.  PDT+ bugs fixed include several key binding ones plus the focus PDT+ bugs 21895, 21832, and 21610. (hyatt, saari)
  • Stuart Parmenter hooked up Tinderbox to Christmas lights display, so you can see the status of all major platforms at a glance. (pavlov)
  • Everyone triaged their bugs for beta milestones M13 and M14, although ongoing vigilance is needed.
  • The XPToolkit team resolved 99 bugs in this period, fixing 35 these  (includes 13 PDT+).  See our  resolved bug list for details.
  • Priorities
        (current open bugs prefixed with a *)

  • pinkerton: *21847
  • danm: *9614, *10029 and *16248
  • saari: Key bindings
  • hyatt: 19345
  • evaughan:
  • Finish integration of GFX scrollbars into list box (*18895).
  • Begin integration of clip widget removal code.
  • sdagley:
    • *15166 removing 4.x prefs cruft
    • *18399 support selecting items in the Apple menu
    • *17949 nsILocalFile spec is pretty stable now, finish up Mac impl
  • pavlov:  *20185absolute repaint wrong w/GFX
  • Issues

    • Mike Pinkerton has determined that the original clipboard implementation does not appear to scale well enough, and will need to be rethought and rewritten. He'll be doing the work, bug 21847 .

    Eric Vaughan is on vacation through 1/10.

    Jan 09
    Submitted by Peter Trudelle <>
  • Mike Pinkerton fixed some memory leaks where any scrollbarframe was being QI'd to a box (pinkerton).
  • David Hyatt  (hyatt):
  • wrote first draft of XBL - The Extensible Bindings Language,  revisions should be posted on real soon now.
  • Fixed tree widget attributechanged and offscreen reflow problems for mailnews.
  • Stuart Parmenter (pavlov):
  • Worked with Alec Flett (alecf)  to get tree scrolling faster on Linux.
  • Fixed file picker being pulled up from modal dialog bugs on Linux.
  • Steve Dagley worked with the NSPR group to land some NSPR change on

  • Thursday that had flamed the Mac builds briefly Wednesday night. (sdagley)
  • The XPToolkit team resolved 38 bugs in the past week, fixing 13 of these, including 2  PDT+.  For details, see our  resolved bug list .
  • Lowlights

    • Several cycles lost to nasty strain of flu.
        (current open bugs prefixed with a *)
  • All: Keep on top of beta bug lists, so they are minimal and well understood.
  • pinkerton:  *21847 [feature] Copying large tables hangs Seamonkey
  • danm:
  • *8488 JS calls following window.close() may crash browser
  •  *16248 openDialog method should be renamed
  • saari: *18133 [FEATURE][REGRESSION] some keyboard shortcuts aren't working
  • hyatt:
  • Flesh out XBL spec and partially implement for key bindings.
  • evaughan:
  • Integration of clip widget removal code. (Pork)
  • sdagley:
  • pavlov: 20185 [DOGFOOD][PP]absolute position  elements repaint wrong w/GFX
  • People

    • Mike Pinkerton was on vacation through 1/5.
    • Stuart Parmenter was on vacation through 1/3
    • Eric Vaughan is on vacation, returning 1/10.
    AIX/HP Port
    Jan 10
    Submitted by Jim Dunn <>
    • The HP M12 bits (10.20 & 11.00) on Mozilla FTP site.
    • Still fighting with the AIX crash, but determined that the kernel crash was due to bad version of AIX 4.3.2.
    • Cleaned up several more instances of unresolved symbols during link see:
    • Looked at Slamm's build warnings ( and feel that many of these should be fixed.
    • Declaration of `rv' shadows previous local
    • Declaration of `dirent' shadows global declaration
    • I will be in Austin TX the week of the 26th and will be speaking with IBM about Monterey (the joint OS work with SCO on Intel's new Merced chip).
    Mail / News
    Jan 10
    Submitted by Phil Peterson <>
    • 112 bugs fixed since last status report
    • Message display performance is dramatically improved
    • Posted results of weekly UI meeting
    • Bug list for M13 and M14
    • davidmc - 4.x address book import
    • bienvenu - Improve performance of copying messages from IMAP to local
    • alecf - Moving Account Setup prefs into the main Preferences dialog
    • jefft - Trying to reproduce 22129 Can't receive mail, 20064 Save as .txt doesn't work yet
    • rhp ! ! - 22655 Need to parse quoted HTML and pass in char set, 19223 Quoting a multipart/related message creates an incorrect message
    • mscott - Reply to message with image not quoting image, 23408/8985 Make Delete key work for deleting messages
    • sspitzer - Migration and pref stickiness bugs
    • hangas - Out sick.
    • putterman - 18075 Leave incoming server blank crashes, 10881 Context menus for 3 pane
    • chuang - Drag/drop messages
    • ducarroz - 22985 No scrollbars when forwarding inline, investigate quoting performance
    Jan 10
    Submitted by Kathleen Brade <>


    • Steve
      • worked out a plan for handling Kipp's bugs.  See n.p.m.layout posting "What's up with Kipp's bugs? Here's the scoop."
      • categorized all of Kipp's bugs
      • fixed layout bugs 19494
      • fixed editor bugs 18216, 18447, 21032, 20387(partial), 22228
      • started building block/inline/floater regression test.  Fixed a bug in viewer that prevented regression tests and webcrawlers from loading last URL in list (not yet checked in)
    • Kin
      • Spent some time catching up with email.
      • Helped brade look at UMR/Crash problem having to do with mouse events.
      • Closed 20319 Native Notifiers are getting leaked.
      • Triaged new editor bugs for beppe who is out on jury duty.
      • Did some preliminary debugging for bugs to give more details before passing them on to others.
      • Sat with akkana to try and reproduce bug #22422 (linux repaint problems), but couldn't get it to happen.
      • Spent some time rewriting nsRangeList::GetFrameForNodeOffset() for bug #21029 and trying to figure out the impact to caret placement. Got thumbs up from mjudge to check this in, but also want jfrancis to play with it to make sure the change didn't affect any of his stuff.
      • Reviewed some code from mjudge.
    • Charley
      • Monday - Wednesday spent doing a "Historic Rt. 66" road trip in Arizona. Just wait for the video!
      • Thursday and Friday: Plowed through mail and did mostly bug triage and testing. Worked on M13 bugs.
    • Akkana
      • Spent lots of time eating dogfood, filing bugs, making a list of the most annoying bugs, and helping to diagnose and, when possible, fix them.
      • Triaged my M13 bug list, got down to two M13 bugs.
      • 23169: fixed the inability to split lines in text areas in linux release builds.  This turned out to be an uninitialized variable, and I found several more, which weren't showing up on the warnings pages because apparently that warning only shows up in optimized builds (!) and Mac and Windows people don't see it either.  This is unnerving.
      • Spent some time helping Steve diagnose 21177, testing, pinning it down to a minimal test case, and staring blankly at the code vainly hoping for insight into how sizes are calculated so as to be able to help fix it.
      • 16015: Added a few missing Unix key bindings.
      • Some work on 490: added enough formatting to allow posting to news servers in most cases.  Discussed with Joe the best way to add formatting in the middle of text nodes; we didn't reach a conclusion, so the bug is still open.
      • 22655: Added an API for mail/news to use to pass in a charset for quoted or otherwise inserted html.
      • Fixed 15275: middle mouse "paste" of url into browser's content area.
      • Helped track down various new clipboard and key binding / controller bugs.
    • Joe
      • [This is probably way too much detail.  Just in case any one of these items is something you wanted to know about...]
      • worked a bunch more on caret hopping problems.  This fixed bugs: 22851, 21346, 22205, 22206, 22958, 22242  (Thanks to Kathy for verifying two of these for me.)
      • redid paragraph splitting code, which had gotten very rusty since we don't ordinarily make paragraphs in mail-compose.  This fixed bug 22233, plus a bunch of unreported paragraph splitting bugs.
      • added in some rules code for mail quoting.  This fixes bug:  19979   (extra blank line showing up in mail that has quotes)
      • partial progress on block transformation work: unlisting a list now works mostly correctly again, instead of merging all the former list items into one run of text (no bug number).
      • Moz-br's are now added in one more circumstance: when you have a br at the end of some inline content that is followed by a new block (like a list, table, etc.).  This is needed for the same reason that the other moz-br's are: to generate a blank line that the user expects after hitting return. (no bug number)
      • did some more DTD-related work to enable the editor to check if you should be able to type given the current selection.  This will prevent the user from typing into lists (as opposed to list items) or into table rows (instead of cells), etc.  No bug number is associated with this.  This involved some very minor hackery on the htmlparser which Rick can remove when he provides a better a solution.
      • fixed bug 22944: inserting an <A> in a table splits the table.  (Need to talk to Charley about this - had to turn some of his code off that I assume he wants to change.)
      • Made some progress on text paste performance, but it's still too slow.  That's 19273; leaving it open for now to continue looking at this.  At least you won't see the spastic cursor anymore.
      • thought some about wrapping long lines for html output (needed for html mail).  Note that this is not about wrapping visually, but about wrapping the resulting html source that gets sent to the mailer.  Akkana tried out a solution here and got unexpected results.  I need to figure out what's going on here (apologies to Akkana for delay).
      • fixed bug 15258.  This was a bug involving using left-arrow to move "beyond" the beginning of the document, and then getting an assert if you tried to type there.  I now check for selections outside of the body and sanitize them if needed, but I'm not sure why left-arrowing is capable of getting us out of the body.  This may be an underlying selection or layout bug.  I'll talk to Mike about it.
      • fixed a bug where code that merged adjacent text nodes would merge the non-editable "formatting" textnodes, which caused all sorts of woe.  (no bug number)  Also added code to prevent selection from ending up inside a non-editable text node.
      • I think I fixed 11994, an IME bug.  But I don't have a way to test this one (it's only certain system/IME combo's).  Awaiting feedback from Frank about how the proposed fix is working.
    • Kathy
      • triaged/tested a couple of Joe's bugs
      • worked a little on #20954; currently need to get some code reviews from vidur or joki
      • worked a little bit on #22288 (setting the default prefs when creating a new editor window)
      • reported several blocker problems regarding news
      • tried to track down problem I see on Mac regarding e-mail which doesn't make links clickable; rhp and I are stumped :-(
    • Mike
      • Resolved and fixed alot of bugs. I am on bug elimination mode. I am trying to get bug numbers down since that is evidentally the main focus here in m13. (as opposed to core technology/ feature/ underlying design flaw fixing)
    • Simon
      • had a great vacation


    • There are 253 total open bugs assigned to people on the editor team
      • 11 bugs with no milestone set
      • 57 open M13 editor bugs


    • Steve
      • started migrating into the layout team (over troy's strenuous objections!)  ;-)   Expectx to spend time like this for the next couple of weeks:
        • 50% layout
        • 30% editor
        • 10% webshell
        • 10% other (travel, working with Marc, working with Hyatt and Saari on focus issues, etc.)
    • Kin
      • Start working on bug #12825.
      • Take a look at any other caret problems
    • Charley
      • With latest cold just about over, hit the week running and attack those M13 bugs.
    • Akkana
      • Work on my M13 bugs, 490 and 20603.  490 mostly needs a decision on where the formatting should be inserted for long text nodes (maybe I'll bring that up at the meeting).
      • Help with other people's M13 bugs.
      • Continue to eat dogfood and help fix bugs that are dogfood stoppers or annoyances.
    • Joe
      • Big surprise: working on M13 bugs.  If we don't get too badly hammered with last minute M13 issues, I think I'm on track to close them all out prior to M13 deadline.  Note: I NEED HELP ON BUG 17303.  This is an M14 bug so don't do anything now unless you have no M13 duties - I'm just giving advance warning that I need some pointers on what's going on with this bug.  If someone wants to lift a bug off me, 18284 is M13 and probably doesn't require an ability to read my mind (unlike trying to fix some of the rules code problems).
    • Kathy
      • M13 bugs
        • bug #20291 may be postponed since help can't be opened at all on Mac (dependency)
      • prefs stuff (finalization)
      • Image Map Editor contribution expected very soon; work with Dan and Brian on this
      • work with pnunn to have image dialog get size info from imglib
      • hopefully catch up a bit more in the newsgroups
    • Mike
      • has 9 m13 bugs; hopes to get to 4 by the end of the week. (i would love to get them all but some are the generated content jazz. ewww)
    • Simon
      • M13 bugs


    • Steve
      • Nisheeth won't be done with reflow coalescing for several weeks.  So he won't be able to get into Kipp's code in any meaningful way until February is my guess.
    • Kin
      • Spoke to pierre earlier in the week about style system support for bug #12825. He said he will ping me after he checks in his part.
    • Joe
      • Needs help for bug 17303 (M14)
      • Could use help with bug 18284 if someone has time
    • Mike
      • needs lots of luck with his generated content class of bugs
    Jan 10
    Submitted by Jim Roskind <>
    In the past I've written up some status that possibly helps to explain what a lot of the Netscape engineers are working towards.  Having come back from our holidays, I thought I'd put out yet another such posting.

    This message lists status, some near term goals, and the priorities that a lot of us are working on. As I comment in each such email posting, nothing I say is "binding" upon Mozilla and non-Netscape developers.  My guess is that we all (including Mozilla in general) have such allied goals (seeing a new world-class product ship, and ship soon), that many folks may choose to join us on some of our near term efforts. ;-)

    STATUS: "Engineering Dogfood"

    The big achievement that appeared in December was that we reached a "consensus engineering dogfood" status here in Netscape Client Product Development (CPD).  At a CPD meeting on 12/22/99, a vote showed that in excess of 50% of the staff working on the project was using Seamonkey to do more than half of their browsing and e-communicating.  This status marked the culmination of a Netscape internal thrust to drive to zero the number of "internally critical" bugs (a.k.a., PDT+ dogfood bugs). 

    The major benefit of this status is that now, in addition to the amazing array of open source contributors testing and commenting on the product, more than 50% of the developers here at Netscape (who I think still form a majority of developers as a whole) are beginning to depend on the product.  In the past browser development efforts, when we've reached "dogfood status" (relates to the business concept that a "company ! ! should eat its own dogfood") we've found that quality improved rapidly.  Peer pressure amongst user-developers is very powerful, and this is all exploited as of "dogfood" status :-).

    To all the contributors to the seamonkey open source project I say both thank you, and congratulations! :-)


    We all share the larger goal of shipping a product.  Toward that end, the step we must take before doing so is to create and ship an alpha, or a beta.  Mozilla is talking about the possibility of having M13 act as an alpha.  Within Netscape, we are now talking about making M14 the basis of either an alpha or beta release of some sort.  The details are still being decided, but the near term goal at Netscape is clear: To ship a pre-release variant of Seamonkey.

    In focusing on this potential Netscape release, managers and engineers have been aggressively triaging their bugs into target fix versions of M13 and M14.  The goal is to get anything out of our way that is not critical to the release, and to focus on all gathering together at M14 with an alpha/beta quality product.

    The intent is for M13 to freeze (for regression fixing) on midnight 1/17/2000.  We expect that the regression work will take less than a week if we can! ! hit that date with darn near zero M13 bugs.  You should all expect to see a lot of fixes, and retargetting going on this week as we work towards this first goal.

    The M14 tree freeze is planned for 2/15/2000.  We expect that we'll need to work harder during that freeze to not only remove regressions, but also to improve general quality, before creating a Netscape branded release.  With that expectation, the "shake-n-bake" period associated with the M14 checkpoint will probably be longer.  The details still need to be discussed, but that is at least some tentative planning for how M14 will form the basis of a Netscape branded release. If history is any indicator, such a release will reach the hands of millions of folks.  We have the option of branching, etc., but we'll wait till we are closer to that date before commenting further.


    To move forward, folks at Netscape are focused on the following items (in order of importance):
    1. Maintaining quality of daily builds, and keeping the tree green
    2. Removing any "PDT+ dogfood" bugs that appear, and might drive away CPD usage
    3. Repair of any M13 bugs
    4. Repair of any M14 bugs
    For engineering managers, the goal is to negotiate the target fix versions for bugs into M13, M14, and later, based on plans to reach a possible beta release in M14.  For each checkpoint, the goal it to hit the freeze date (1/17, or 2/15 respectively) with zero outstanding bugs.  Given that today there are a whopping 800 plus M13 bugs pending, you can anticipate that there will be a lot of triage and re-scheduling.

    For cases where managers or engineers are not sure if a bug is "beta critical," the keyword "[beta1]" should be added to the summary line.  This will cause the PDT to try to provide a Netscape priority ruling (remember, we're not insisting that all of mozilla play by our rules... but we can always hope) as to whether this needs to be done for beta.  For most M13 and M14 bugs, the status will be clear, no special annotation will be added, and the PDT will not have to provide assistance.

    The approach to mediating "[beta1]" bugs is identical to the approach taken for "[dogfood]" bugs.  With dogfood bugs, the annotation to the summary attracts attention of the PDT, and allows the PDT to make a ruling with a broader view towards a common goal.  Some folks are always upset by any such ruling (after all, it only gets a dogfood annotation if someone claims/nominates it as such), but to move Netscape as a team, we needed to focus our efforts on the critical items.


    A lot of folks within Netscape (including me) are using Seamonkey on a daily basis.  With this level of usability, we're hoping to stretch to become usable as a beta product very soon now.  If we succeed, it will be as early as a variant of M14.  If you want to help see the product get a lot more visibility, please consider helping us reach alpha/beta quality in time for the M14 freeze.  I'm sure we'll then all have a lot of reasons to be happy. ;-)



    ---Opinions expressed are mine, not Netscape's---
    Jan 12
    Submitted by Ben Goodger <>
    Previously, the Preferences dialog was maintained by a back end interface known as nsIPrefWindow. Apart from being in C++ (and therefore evil), nsIPrefWindow forced you to use the id attribute on the elements in your Preferences panels for twisted purposes. The New PrefWindow is a panel switching and preference saving mechanism implemented entirely in JavaScript, connecting to nsIPref directly for storage and retrieval of settings, and offering much more flexibility, as well as code sharing with the Create Profile Wizard. Since it's in JavaScript, its easier to hack extra features in.

    During the process of updating the "front back end", most of the panels were given an upgrade in appearance (with the exception of Mail). This upgrade is meant to bring the appearance of the Preferences dialog more closely to what we hope it will be like when we ship.


    Previous Updates