Mozilla

This week we have reached a whopping total of 21 different M13 packages. This includes packages on 7 different platforms and three languages (English, Japanese and German). This week's friends of the tree include these package contributors:

• Kevin A. Puetz <puetzk@iastate.edu> (PPC Linux tarball)
• Anton Blanchard <anton@progsoc.uts.edu.au> (Sparc Linux tarball)
• Pete Collins <pete@alphanumerica.com> (i386 FreeBSD tarball)
• Furukawa Ryoichi <oliver@1000cp.com> (i386 linux, mac, win32 in japanese)
• Robert Kaiser <KaiRo@StarTrekMail.com> (win32 in german)

See the new document "Building A Mozilla Distribution" http://www.mozilla.org/build/distribution.html for instructions on packaging Mozilla on Unix. I could use contributions for other platforms as well.

Highlights
 

Mike Pinkerton (pinkerton)

Unicodified the clipboard, so that clients of clipboard/d&d should no longer use text/plain, but should always use text/unicode instead.

Made clipboard/d&d fully i18n'ized, both incoming and outgoing.

Put Dave Hyatt's XBL doc on the XPFE website.

Updated Fizzilla (Mozilla for MacOSX) documents.

Fixed  21477 , so that long, flat bookmark lists are now usable via xp-menus.

Stuart Parmenter sped up Linux drawing performance by a factor of 2! (pavlov)

Steve Dagley (sdagley):

Chased down yet more regressions from the nsLocalFile landing.

Made form file attachments work on MacOS.

Eric Vaughan (evaughan):

Got GFX listboxes (selects) up and running with GFX scrollbars. This should eliminate the last of the native widgets.

Got the browser to come up with only 10 reflows,  instead of the hundreds in the old reflow count.  The savings in treewalking and painting of elements should yield a big performance win.

The XPToolkit team resolved 93 bugs in the last week, fixing 28 of  these, including  13 PDT+.  For details, see our resolved bug list.

Lowlights

Chris Saari has realized that the focus issue in bugs 24370 & 18130 is a lot more difficult than he thought.  It turns out that people are using the onload handler to set the initial focus for a dialog, and the onload handler is called before the dialog is shown. On MacOS that focus will subsequently get blown away when the window is shown, causing an activate event, which causes a focus event. Even if he disables the activate initiated blur, the initial focus won't work properly on MacOS because there is no front most window to flow the event to if the dialog isn't shown yet.  Anyone have some insight on how a solution could be implemented for beta1?

Priorities
    (current open bugs prefixed with a *)
 

pinkerton:

Meet with Metrowerks about OSX development tools (with saari) on Thurs

Try to remove PowerPlant and WASTE from the app

Assist macdev in the upgrade to Pro5 on MacOS.

 *16388 [M14] - [FEATURE] Right-click (context) menu displaced on pages with frames

* 17042 [M14] - Menu lockup after rapid clicking

saari:

Move command dispatcher with Hyatt on Monday. Deal with the firestorm to follow.

*Continue to look at 25434 [M14] - Crashes during logon , an infinite recursion with JS/focus when logging onto a web page. Not sure if it is the page's fault or ours yet. Not sure what to do about it in either case.

Get a linux build that doesn't crash on launch and look at  19973 [M14] - Carets in every address bar (carets not disappearing when you switch between windows).

hyatt:

 25303 FILE/FTP dir listings broken

 25432 Cookie Manager freezes Seamonkey

 24519 Reply-All picks up only 3 addresses

 24911 ]Profile picker shows no profiles

evaughan:

* Finish dirtybox code and checkin.

 20521 [M14] - Scrolling before a page finishes loading wrecks havoc

 23521 [M14] - Scrolling thread pane in mailnews causes whole window to reflow

 23857 [M15] - [PP] Sidebar fills entire screen on splitter click

sdagley:

 22961 [M14] - [PP] Mac: select local file uses colons instead of slashes for path

 2611 [M14] - loading complex (cnn.com) pages much slower on Mac

pavlov:

26502 [M14] - Linux rendering performance is MUCH slower than windows.

*20496 [M14] - [DOGFOOD][REGRESSION] Navigation Toolbar appears bad

danm:

•  *26283 [M14] - cookie-alert/IMAP/NNTP/POP dialogs coming up blank, subsequent app hang/crash.
•  19221 [M14] - Dialog Modality added for Bug 10000 causes bad UE bustage

Issues

Regressions! You hate em?  We hate 'em too!  We have been having way too many of them during the last couple of weeks. Some of them are caused by the person whose feature has regressed, but many are caused by seemingly unrelated checkins.  This wastes a lot of time investigating and fixing problems that should never have occurred, and makes it difficult for everyone to get builds that work. We all need to much more carefully  test all possible affected components before checking in changes.

People

• The XPToolkit team all enjoyed an afternoon together offsite last Wednesday, racing against the clock at the Malibu Grand Prix, playing video games and air hockey, eating, drinking (although most had nothing stronger than root beer), and generally being merry.  Sound like fun?  See the next item:
• The XPToolkit team has an opening for a strong software engineer who learns quickly, and has solid interpersonal skills and a positive attitude.  You'll have to demonstrate development proficiency using C++, and superior problem-solving skills. Experience with Linux/X, Dynamic HTML, XML, CSS, Javascript (or VB), and COM would be a plus.  If you're qualified and interested, or know someone who is, please send me a resume and a few words on why this is a great fit.

Where is this schedule going for Netscape?

As I've mentioned in previous status commentaries, Netscape staff is hoping to be able to use the M14 checkpoint as a basis of a commercial beta or alpha.  Our hope is that we'll be able to take a series of bi-monthly checkpoints M14, M16, etc. as progressively better baselines for pre-releases (Netscape will typically provide additional QA, and very very very selective additions to a checkpoint, to construct a Netscape branded release).  Eventually, after some TBD number of such beta's, we hope to produce an actual FCS (First Customer Ship) of a full blown Netscape branded production release. To make that plan a reality Netscape is driving its in-house contributors to Mozilla to focus on M14.

We currently believe that by M16 Mozilla will probably be pretty feature complete.  We're also hoping that M16 will be a point at which most if not all public interfaces will stop evolving.  In addition to any of our near term goals, you'll also see effort to supports Mozilla's target in the M16 freeze

How does M14 tie in? What are Netscape's near-term priorities when contributing to Mozilla?

Netscape's first step is to itemize some number of bugs that our marketing department selects as "beta stoppers." We've begun marking such bugs with the "beta1" in the keywords field, and getting the PDT (Product Delivery Team, which includes marketing) to approve the nominations.  Approvals are made by marking the status whiteboard with "PDT+."  Those two tags, when searched for simultaneously, provide a list of what Netscape feels are initial beta-stoppers.  Inside Netscape we're pushing our engineering team to add an extra level of focus on driving down this bug count, so that M14 has a *shot* at being the basis of a Netscape branded pre-release. (We're still giving an even higher priority for Dogfood/PDT+ bugs, but that is a clear need for the Mozilla codebase in general).

If M14 has relatively few Netscape "beta1" PDT+ bugs, then what will happen?

Assuming the M14 checkpoint (scheduled to freeze for stabilization on 2/15) has relatively few beta stoppers (something under 100), then we'll probably try to help resolve most of the stoppers during the M14 freeze.  Just as we did in the Dogfood thrust (re: M12 release in December), we'll try to restrict checkins during the freeze to significant regressions, and to beta1/dogfood stoppers.  We expect that after about a week or two of stabilization, we'll be down to the point where few engineers are still able to contribute to the "constrained" M14 development.  At that point (number of beta1 stoppers will be very low, probably under 20, and possibly around 10), we'll branch for finalizing M14.  The trunk will then open in some format for continued work towards M15 and M16, while the M14 branch gets its final adjustments.  The M14 branch will probably get worked on for less than a week before an M14 final is tagged (put on the wire).  At that point, while most development goes forward on the trunk, Netscape will continue to "qualify" a continuation of the M14 branch as a basis of a commercial release.  We haven't figured out if we'll "branch from M14," or continue on the M14 branch... but that is small potatoes and TBD.  Eventually Netscape's will decide "enough is enough" and the resulting "M14 plus a few fixes" will get a Netscape branded blessing.

That last paragraph is all about the "happy ending" or "happy beginning" of getting the Netscape distribution system going and releasing branded versions of Mozilla.   Inside Netscape, we're all pushing for that "happy" story... but we're also watchful of the "less happy story."  The "less happy story" starts with:

What will happen if at M14 freeze, there are still a ton of beta1 stoppers?

If on 2/15, we still see too many beta stoppers to reasonably drive an M14 derivative to a commercial release, then we shoot for an M15 based Netscape branded release.  Netscape staff would help Mozilla quickly into and out of a brief M14 freeze/branch/ship (just like a typical checkpoint, as was done with M13).

I won't dwell on this "less happy" option, as I don't want it to happen. I want to get the world psyched about this Mozilla project being real.  I believe that to tell the world that this browser/mailer free source effort is _real_, we need to get commercial vendors to release derivatives of the Mozilla tree, and I think that Netscape will probably be the first such distributor.  The sooner that happens the better.  The sooner that happens, the easier it will be to get additional contributors.  The sooner we get a commercial release, the sooner we'll have an FCS. :-).

What can I do to help get a (Netscape) commercial beta version of Mozilla out sooner?

For the many contributors to Mozilla, there are a variety of talents and contributions that could be applied to help our effort.  First off, if you have any PDT+ bugs, and you can nail them sooner than later, that would be a big help.  Next, if you already have some bugs that have been nominated to PDT+, and claim to have been fixed, but you know otherwise, please chime into the bug report asap.  If you know of some bugs that you think are beta stoppers (example: all too common crash scenarios?  embarrassing user experiences?  terrible performance when compared to Navigator 4.x?), then please nominate the bug by adding only the "beta1" keyword to the bug (only the PDT gets to do approval... sorry).  Such nominations with approval will attract resources from across Netscape to resolve the issue before M14 goes out.

Can we really get the codebase in shape by M14 to achieve this milestone?

The road won't be easy.  We are currently sitting at around 300 PDT+ (approved) bugs, and it is only a bit over a week till our 2/15 freeze.  The good news is that I've watched our bug kill rates in the past, and we regularly achieve a net of 200 or better net resolutions in a week.  I've seen kill rates as high as 300+ in a week.  Better yet, many of the "beta stoppers" are actually crashers, and menu polish bugs, which are often not that difficult to resolve.  The bad news is that there are some hard bugs, but I said the road wouldn't be easy.   The real question is:  Can the Netscape staff get focused on these bugs, and work to vanquish them?  Will other Mozilla contributors think that this plan and quest are worth joining, and pull with us? 

IF the answer to those last questions is yes, then I'm sure we can achieve this milestone as part of the M14 checkpoint. I know a lot of staff at Netscape that is shooting for that target, and I'm hopeful that others will join us.

Thanks for listening, and thanks in advance for any and all help in our quest,

Jim

---
Opinions expressed are mine, and not Netscape's

Shane and I don't have much to report this week for AIX & HPUX. Mostly we are trying to get the Seamonkey (Commercial) builds going.

Highlights

• 78 bugs fixed last week! If that isn't a weekly record for the group, it's real close. Great work everyone!
• Repeating this from last week: drag/drop of messages works.
• Auto-complete now works against nickname too
• IMAP interoperability problems related to namespaces (e.g. the Cyrus server) have been fixed
• Many i18n fixes
• Fully integrated with single sign on for password management
  

Priorities

• Need to make a bigger dent in our beta stopper bugs.
• More of the M14 list will doubtless be moved off, since it's too much for one week.

  ---

• bienvenu - 7130 Use UTF-7 for IMAP folder names, 26596  Non-latin1 characters not showing up correctly for IMAP folders
• alecf - 25729, 21654 Windows Large Font issues, 26245, 26413 Account manager problems
• jefft - 26657 IMAP assertion "hierarchy separator unknown", 26547 Unable to move/copy messages in IMAP, 23089  Selecting "undo" after deleting message causes trash folder to load
• rhp - 22090 Make AppleDouble decoding work, 16797 Allow additional File Carbon Copy on outgoing messages
• mscott - 20597 Click http link in mail message doesn't bring up browser window if one isn't already open. 20283 Infinite loop when anchor has javascript:history.go(0)
• sspitzer - 26633, 26308, 26485 Mail/news dialog box problems on Mac,
• hangas - 22558 Need key bindings in mail window, 25348 Delete button gets stuck on disabled
• putterman - 26131 Sorting threads in three-pane is very slow, 26456 IMAP folder load performance does not meet beta1 criteria
• chuang - 22986 Address book sort is extremely slow, 24857 Crash on opening new abook after deleting abook
• ducarroz - 23540 Pref UI for mail default charset, 25364 We leak one webshell per address in the compose window

This weeks priorities:

• Kin:
• this is the big week for Kin and his wife -- their first baby is due -- any moment
• work with kmcclusk on bug 24597
• 6 open M14 bugs
• Kathy:
• continue to work on M14 list
• take management hand-offs from Beth before she leaves
• 5 open M14 bugs
• Joe:
• work on font increase/decrease problem, this has proven to be more difficult than initially thought
• fix ALT+numpad keystrokes bug (PDT+)
• work on font face feedback for the user.
• 9 open M14 bugs
• Simon:
• get the command updating stuff done
• continue to work on M14 bugs
• 12 open M14 bugs
• Mike:
• continue to work on the generated content issue
• work with Joe on the ranges implementation.
• work with Charley on cell selection issues
• 12 open M14 bugs
• Charley:
• finish Page Properties dialog
• finish beta 1 table editing goals
• 10 open M14 bugs
• Akkana:
• continue to work on 9266 (disable javascript)
• work with Eli on bug 24905
• 2 open M14 bugs

Highlights:

• 51 editor bugs were resolved this past week
• 57 open M14 bugs, 6 are PDT+

Lowlights:

• There are currently 213 open Composer bugs (M14-M20

Accomplishments:

• Kin
• did several code reviews
• checked in fix for 26100, 20387
• debugged 25029, ended up being an AIM CSS bug
• did lots of debugging for bug 24597
• helped triage editor bugs
• Kathy
• fixed paths in Mac project files (for Simon and me)
• recruiting and on-campus interviews at University of Michigan
• editor bug list triage
• Joe
• fixed several inline style feedback problems
• implemented reflow batching for the editor
• code reviewed fix for plaintext editor bug
• fixed password field bug
• Simon
• continued work on the command updating/dispatching
• added some more necko protocol DLLs to the Mac build for valeski
• helped Ben Goodger work around some problems getting strings from string bundles in the profile manager
• worked with Chris Yeh to figure out why Talkback was not working in optimized builds
• fixed 6553, 25695, 25927, 25952, 25962, 25944, 25948
• Mike
• build stopped working for no explainable reason and had to re-install VC6.0
• fixed bugs for the keymappings and navigation (20146  23479), the fixes need to verified.
• spent lots of time on the generated content problem (12460).
• Charley
• made great progress on table editing feature work (20973)
• worked on Page Properties dialog (14344)
• worked with Mike on table selection issues
• reviewed Composer Menu spec for Jennifer Glick
• Akkana
• worked on trying to disable javascript within the editor (9266)
• helped with the font size issue
• fixed 26468, 24912, 20603, 18033, 490 and 24635
• worked out work-around for 22505
• triaged lots of key binding and paste bugs

Issues:

• Joe has discovered numerous issues with inline style functionality, specifically when selecting across multiple elements, the end result is poorly constructed HTML.
• No leads yet on open position

People:

• Beth out on sabbatical 2/16-3/29
• Kin out on sabbatical 3/6 -
• Charley was out on Friday (2/4)

Today is a significant day for the NSS and PSM crypto teams.

We completed our code-cleaning work, and shipped to Mozilla the first packages of encryption source code. These pages do a fine job of describing where we are now.  We also added some more documentation which you can view at the NSS and PSM pages.

You can get a glimpse of what PSM (the binary) is all about by running it with Communicator 4.7.

What a great week!

Pav has been hard at work trying to make scrolling faster. This includes creating GCs only when needed and hunting the event queue for mouse motion events. Scrolling is faster, but still kind of jumpy because of the mouse motion event hunting.

I checked in a DND implementation so you can now drag and drop items in mozilla. I also fixed a crash when printing. I've also been trying to finish up some of the last pieces if nsIFile.

Erik has been hard at work trying to make fonts look sane under unix and has done a lot of good work. On a lot of systems the menus look reasonable now and many web pages look a lot better. Good work, Erik!

Previous Updates