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:
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.
- Kevin A. Puetz <email@example.com> (PPC Linux tarball)
- Anton Blanchard <firstname.lastname@example.org> (Sparc Linux tarball)
- Pete Collins <email@example.com> (i386 FreeBSD tarball)
- Furukawa Ryoichi <firstname.lastname@example.org> (i386 linux, mac, win32 in
- Robert Kaiser <KaiRo@StarTrekMail.com> (win32 in german)
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.
, 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
Chris Saari has realized that the focus issue in bugs 24370
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?
(current open bugs prefixed
with a *)
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.
[M14] - [FEATURE] Right-click (context) menu displaced on pages with frames
* 17042 [M14]
- Menu lockup after rapid clicking
Move command dispatcher with Hyatt on Monday. Deal with the firestorm to
*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).
FILE/FTP dir listings broken
Cookie Manager freezes Seamonkey
Reply-All picks up only 3 addresses
]Profile picker shows no profiles
* Finish dirtybox code and checkin.
[M14] - Scrolling before a page finishes loading wrecks havoc
[M14] - Scrolling thread pane in mailnews causes whole window to reflow
[M15] - [PP] Sidebar fills entire screen on splitter click
[M14] - [PP] Mac: select local file uses colons instead of slashes for
- loading complex (cnn.com) pages much slower on Mac
- Linux rendering performance is MUCH slower than windows.
- [DOGFOOD][REGRESSION] Navigation Toolbar appears bad
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.
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,
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
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
Thanks for listening, and thanks in advance for any and all help in our quest,
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.
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
- 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
- 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:
this is the big week for Kin and his wife -- their first baby is due --
work with kmcclusk on bug 24597
open M14 bugs
continue to work on M14 list
take management hand-offs from Beth before she leaves
open M14 bugs
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.
open M14 bugs
get the command updating stuff done
continue to work on M14 bugs
open M14 bugs
continue to work on the generated content issue
work with Joe on the ranges implementation.
work with Charley on cell selection issues
open M14 bugs
finish Page Properties dialog
finish beta 1 table editing goals
open M14 bugs
work with Eli on bug 24905
open M14 bugs
51 editor bugs were resolved this past week
57 open M14 bugs, 6 are PDT+
There are currently 213
open Composer bugs (M14-M20
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
fixed paths in Mac project files (for Simon and me)
recruiting and on-campus interviews at University of Michigan
editor bug list triage
fixed several inline style feedback problems
implemented reflow batching for the editor
code reviewed fix for plaintext editor bug
fixed password field bug
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
fixed 6553, 25695, 25927, 25952, 25962, 25944, 25948
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).
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
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
Joe has discovered numerous issues with inline style functionality, specifically
when selecting across multiple elements, the end result is poorly constructed
No leads yet on open position
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
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!