|
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."
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
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)."
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.
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.
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.
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.
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.
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
- 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.
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).
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
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
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."
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.
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
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.
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."
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?"
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
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."
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
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 XP-COM 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 XP-COM 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]
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.
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
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.
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.
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."
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.
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.
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."
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.
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.
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."
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.
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."
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.
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
"
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
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.)
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."
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."
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.
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."
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 the backend and the XFE."
To read more about the state of Composer, check out mozillaZine.
Akkana Peck also has another module update for us: "We tried to
turn on MOZ_MAIL_COMPOSE by default, but there were some glitches involving
files used in the internal build. Most of those have been fixed; expect
to see mail compose turned on by default for Unix any day now.
Win32 work on multipart MIME in the embedded editor is progressing nicely,
and should appear soon, which will also mean turning on MOZ_MAIL_COMPOSE
on Windows. No one has signed up to write a mail compose window, though,
so the embedded editor will be the only UI unless someone volunteers.
We are in great need of help getting this feature tested and implemented
on the Mac -- please contact us if you're interested in helping."
From Rick Gessner, we have this info:
A great deal has changed in NGLayout:
- Plugins are online
- Applets are coming online
- CSS1 property support continues to improve
- NGLayout-Mac is finally up and running
- DOM level 1 is coming online
- Performance is up
Troy Chevalier sent a note with some updates on the work of specific
programmers:
Kipp:
- Landed the revised block & inline code: refactoring of the code with
better code reuse; better left/right margin support, and better handling
of blocks inside of inlines Part of this work included reworking the
way that list-items work, both the way that they position themselves
and the way that bullets are placed and the way that bullets are numbered.
- Hooked up the content attribute change methods to the document/presentation-shell/frame
system. Consequently, setting attributes from the DOM (Javascript or
C++) will now trigger the appropriate layout response. Note that only
a few frame classes have been modified and only a few attributes are
hooked up.
Troy:
- Completed frame construction changes. Moved handling of ContentDeleted
and ContentReplaced notifications into the style system.
- Removed mFirstContentOffset, mLastContentOffset, mLastContentIsComplete,
and mChildCount from nsContainerFrame. Eventually nsContainerFrame will
go away and what little is left will be merged into nsHTMLContainerFrame
Steve:
- Added support for table-layout=fixed. We completely skip pass 1 reflow
and doesn't require max-element-size which substantially speeds up initial
table reflow
- Moved all frame initialization (and related logic) into the various
table frame Init() member functions
Here's more detail on the Mac NGLayout progress that Done Cone submitted
to the checkin newsgroup: "You can now break out your macs and see
Raptor -- LAYOUT Raptor Mac now builds(again) and lays out.
- Double buffering is not working, so to actually SEE it layout you
need to uncomment out the #define NO_DOUBLE_BUFFER in nsViewManager.cpp
in the viewer project.
- Updated the widget library for resizing and widget placement.
- Images now load but local files need a special hack (different path,
local file syntax). But it works!!! I basically put in a hard coded
image path c string into nsFrameImageLoader::Init's method.
- Animated images flicker alot, need to fix this also.
- Some widget placement problems. I know what the problem is, just
need to fix."
Libmocha (JS-only DOM level 0)
|
September 25th
|
| Submitted by Mike McCool <mlm@netscape.com> |
Mike writes, "The multithreaded libmocha changes are landing today
at 1:00, which will be good. =) I will be gone next week, but after that
I will be integrating 4.x bug fixes into the Mozilla code."
RDF and HT (HyperTree)
|
September 25th
|
| Submitted by Robert Churchill <rjc@netscape.com> |
Robert Churchill writes in, "We're finishing up reflection of Shack
objects (implementations of the HyperTree layer above RDF) into JavaScript.
This will enable JavaScript to reference any Shack object embedded in
a HTML page and obtain its contents and properties (such as whether a
node is selected, enabled, etc)."
Dan Veditz writes in, "Looked into converting the Netscape registry
into an RDF datasource. The changes required look too extensive to consider
for 5.0, especially given how far behind we are on SmartUpdate. We'll
merge over the changes from 4.5 and leave it at that until a later time."
Dan Veditz also writes in with the SmartUpdate update: "Progress
on design of new UI flow. 4.5 still sucking up time from the team. Not
much progress to show until we complete the conversion of all the Java
code into C -- it's not usable until that part is finished."
Brian Ostrom writes, "Last weekend's builds (MOZ_LITE only) broke
all over the place. I cleaned up what I could and checked in a few minor
tweaks. MOZ_LITE builds should be better off now.
Thanks to Zoltan Varga (zvarga@gw.cdk.bme.hu) for pointing me at a gcc
2.8.1 distribution (no source, unfortunately...) for QNX. It seems to
be working properly, and that port is starting to look vaguely hopeful."
The WinFE is fixing bugs and wrapping up 5.0 features.
We're working on configurable chrome and on the Aurora tree widget...
improving the behavior of both and doing usability testing of different
behaviors and looks for the toolbars and trees.
Mike Pinkerton writes in with this update: "We are in the process
of upgrading the mac to build with CodeWarrior Pro4 (available next week)
and getting more appearance manager support (and MacOS8 support) into
MacMozilla. We also rebuilt the strings library so that we get rid of
N-thousand 'STR ' resources."
Nisheeth writes in with a quick update:
"Eric Pollmann is working with Mike Shaver to make layout get style
information from the new DOM tree and solve a bunch of style inheritance
bugs."
- Steve: Tables switched over to the new content model and new frame
layout scheme. Some minor table layout fixes.
- Troy: More work on the new frame construction changes. All frame construction
now happens in the style system (HTMLStyleSheetImpl), and nsIContentDelegate
is gone.
Libmocha (JS-only DOM level 0)
|
September 18th
|
| Submitted by Mike McCool <mlm@netscape.com> |
Mike writes, "Checkin of multithreaded libmocha was delayed by Mac
issues, which are still being resolved... also, the JavaScript console
may also be getting merged in from 4.x soon."
Eric Bina and JG posted some info about HTTP compression at http://www.mozilla.org/projects/apache/gzip.
They are urging people to get the latest version of Apache and start playing
around with Mozilla's HTTP compression stuff. Internally, we've seen some
monster improvement over low-bandwidth lines: it'd be cool if we could
confirm this in the real world.
There is a first cut at a "smooth progress bar" implementation on PROGRESS_19980909_BRANCH
if people want to pull it, build it, and check it out (or just take a
look at the source and code review it). I hope to land this in the trunk
next week or so.
I pushed some information about "runtime performance tracing" in Mozilla
at http://www.mozilla.org/performance/runtime-tracing.html.
Talks about how to gather statistics about what Mozilla spends it's time
doing (at the "application level" rather than like what a profiler might
collect).
Pam Nunn writes in with this update:
- The Mac Colorsync code is in a branch and will go into test soon.
- Work on making the imglib smarter w/r to the network library is in
progress.
- A bug associated with the Intel MMX optimization will have a fix from
Intel soon. The bug is associated with jpeg image width < 8 pixels.
Developers can either disable MMX option, MMXAvailable, in jdapimin.c
if they can't wait for the fix.
Warren writes, "The project is nearing completion. We're continuing
to work closely with folks from JavaSoft and Apple to resolve the remaining
issues involving the integration of JavaScript security with the Java
security architecture. We're also negotiating with several Unix vendors
to integrate their JVM implementations with the browser via OJI."
Edwin writes in, " On the libpref front, we've been doing a lot
of planning to bring the 4.5 preference and profile manager features to
the 5.0 world. We're not done with that planning yet, but we should know
more in the next week or so."
Brian Ostrom writes, "I'll be doing the first complete set of UNIX
mozilla builds this weekend, so I'll be able to address current build/config
problems very soon. Added support for OpenBSD, ARM Linux, and initial/incomplete
support for QNX (_really_ need to get gcc for QNX; if anybody has info
wrt this, please have them let me know)."
The localization team is figuring out how to make HTML dialogs more localizable.
|
