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.
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.
danm: *9614, *10029 and *16248
saari: Key bindings
(current open bugs prefixed
with a *)
Finish integration of GFX scrollbars into list box (*18895).
Begin integration of clip widget removal code.
pavlov: *20185absolute repaint wrong w/GFX
*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
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.
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 mozilla.org/xpfe 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 .
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.
[feature] Copying large tables hangs Seamonkey
*8488 JS calls
following window.close() may crash browser
openDialog method should be renamed
[FEATURE][REGRESSION] some keyboard shortcuts aren't working
Flesh out XBL spec and partially implement for key bindings.
Integration of clip widget removal code. (Pork)
[DOGFOOD][PP]absolute position elements repaint wrong w/GFX
Mike Pinkerton was on vacation through 1/5.
Stuart Parmenter was on vacation through 1/3
Eric Vaughan is on vacation, returning 1/10.
- 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
- Looked at Slamm's build warnings (http://tinderbox.mozilla.org/SeaMonkey/warnings.html)
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).
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
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)
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.
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.
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
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.
[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.
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 :-(
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)
There are 253 total open bugs assigned to people on the editor team
11 bugs with no milestone set
57 open M13 editor bugs
started migrating into the layout team (over troy's strenuous objections!)
;-) Expectx to spend time like this for the next couple of
10% other (travel, working with Marc, working with Hyatt and Saari on focus
Start working on bug #12825.
Take a look at any other caret problems
With latest cold just about over, hit the week running and attack those
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
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).
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
work with pnunn to have image dialog get size info from imglib
hopefully catch up a bit more in the newsgroups
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)
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.
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.
Needs help for bug 17303 (M14)
Could use help with bug 18284 if someone has time
needs lots of luck with his generated content class of bugs
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
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
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
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):
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.
- Maintaining quality of daily builds, and keeping the tree green
- Removing any "PDT+ dogfood" bugs that appear, and might drive away CPD usage
- Repair of any M13 bugs
- Repair of any M14 bugs
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
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---
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
storage and retrieval of settings, and offering much more flexibility,
as well as code sharing with the Create Profile Wizard. Since it's 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