Firebird -> Firefox

The terms "Mozilla Browser" and "Mozilla Mail" have been abandoned since the book was written.

1.3.2.4 bullet point 4:

"Image resizing. Mozilla proves size controls for images displayed by themselves." ("proves")

"Mozilla supports XLink but not XForms."

(An initiative has started to add XForms support to Mozilla; http://www.mozilla.org/projects/xforms/ )

-----

Perhaps a note should be made for trunk vs. branch nightlies?

-----

"drag 'n'drop" <-- inconsistent spacing

"A port of Mozilla that uses the Qt widget set exists, but it hasn't been maintained for a long time."

Saying that the <span> tag is normally "invisble" isn't quite accurate -- it's normally unstyled, not invisible. span { -moz-opacity: 0; } is invisible :P

Beginning in Chapter Two, you (almost) consistently use "layed" out (vs "laid" out). Is this an Australian English thing, or did I miss an English class somewhere?

"This makes everything more complex, and it's best to ignore overflow until the rest is clear or forever"

(missing comma, or perhaps an ellipsis?: "until the rest is clear, or forever" or "until the rest is clear... or forever"

"is every viewable element that resides at z-index:0, and that occupies a distinct rectangular area, has a frame" (it seems like both commas could be removed)

"If the box does not expand pack does nothing." (add comma? ==> "If the box does not expand, pack does nothing.")

"File | Inspect a window ..." (should be "Window...". Actually, on recent builds, there's not an ellipsis but a disclosure triangle to be hovered, but I guess that's getting too pedantic.)

"different.dtd files" (different .dtd files)

"It separates a widget into three parts: M, V, and C."

... should probably be "Model, View, and Controller"

Right above 4.2:

"What remains is what a button's might do"

"grippys" -> "grippies" ?

I believe that the "proper" name for the latest Apple OS is "Mac OS X", not "Mac OS 10".

"for ( variable-name in object ) statement"

"variable-name" should be replaced with "property-name"... variable-name implies that variable-name is assigned values of the properties, rather than of the property names.

In Ch5, you mention 'the section entitled "Scope Rules"', but Section 5.3.3.4 is titled simply "Scope"

There also appears to be a missing closing-parenthesis:

"JavaScript supports compound statements using the brace characters { and }, but they are different from compound statements in C (see the section entitled "Scope Rules". Bare compound statements aren't that useful in JavaScript, even though they are supported:"

(I assume a ")" should appear after "Scope Rules")

"x = void 0;

X = undefined;"

lowercase vs capital... intentional?

Piddling, perhaps, but in paragraph 5 of 5.3.2.4, you first say "The explicit use of a window. prefix"... and then say "Equivalent prefixes are this and self." (note inconsistent use of prefix. vs prefix)

"hasFeature reports only on DOM support" ("hasFeature()" intended?)

After listing 5.9, you say ".XUL" file, whereas normally you render file extensions in lowercase (".xul") (also with ".INI" later)

In the fourth paragraph after Listing 6.8 (at least in the PDF version), where it says "The <observes> tag uses the element attribute to register...", the word "attribute" is put in a monospaced code font, when it should be the word "element". The wrong word is also monospaced in the next sentence "...attribute attribute" (the first should be bolded, but the second one is)

On page 216 of the PDF: "It's observe() method just returns success." (excise the apostrophe)

This isn't much of an "error", per se, but "drag and drop", "drag-and-drop", and "drag 'n' drop" are inconsistenly used, especially in chapter 6.

Right before Listing 6.16, there's inconsistent use of "de-emphasize" and "de-emphasize"; google says the former is more common (50k vs 10k results) than the latter.

The correct capitalization is "Bugzilla", not "bugZilla" (see http://bugzilla.org and http://bugzilla.mozilla.org)

"To find AOM and DOM properties and methods, there are several approaches." ( followed by a list, so s/\./:/ . Also, in the list, replace "SelectedIndex" with "selectedIndex")

At the top of p.275 (pdf), "To get this effect for free, either keep maxpos small relative to the scollbar's size" (scollbar -> scrollbar)

In the Style Options of ch8, "Mozilla also supports scrollbar : auto" (for consistency with the other examples, both spaces should be removed, though I tend to prefer one space after the colon.)

"Multiline can be set to true" (since it's an attribute, the M should probably be lowercase)

This is a rather strange wording (note double reference to disabled):

"The disabled attribute can be set to true, in which case the command does nothing. oncommand is set to JavaScript code that will be used in place of any controllers that might exist. Other attributes, such as disabled, label, accesskey, and checked are sometimes added to <command>."

In the second sentence of p.302 in the PDF, "enabled" should be monospaced. ("It should check the enabled property of..."

"UpdateCommands()" should be "updateCommands()" everywhere (see http://www.xulplanet.com/references/objref/XULCommandDispatcher.html ; it's been that way since rev. 1.1 in CVS. Yeah, the inconsistent capitalization rules threw me off when I first started working with RDF in Mozilla, since that's one of the only places where most functions start with a captical letter. [edit: as you note in Ch16 :P])

According to Google, "unsupported" is roughly 579 times more common than "desupported", which gets only ~1900 hits. "Desupported" seems like a somewhat awkward word choice, at least to my American-English-acquainted ear.

For 10.4.4: "window.content, id="content" and loadURI()" (comma after "content" ?)

"This use of the term "object" derives from the grammar of spoken language not from technology engineering" (comma after "language")

"File | Save Page As .." (not a full ellipsis; should be File | Save Page As... [remove space])

"View | Show/Hide.. | Sidebar" (again...)

Table 11.3's title is "XML Namespaces Used for RDF Vocabulary", but 11.4 is "XML namespaces used for RDF vocabulary (Continued)" (captialization differences).

In the third paragraph after Listing 11.10:

"The container tag must be supplied with an ID or an about attribute by the document creator"

("about" should be monospaced, but isn't)

Before 11.5, you say this:

"The following attribute applies to container tags:"

...but then list two attributes (ID and type).

For 11.5.2.1:

Should "List", "Subject", "predicate", and "object" be monospaced, to match "XMLLiteral"?

In 11.5.2.2, paragraph 4:

"lthough URNs are supposed to be globally unique, you can make up your own provided your application is isolated from the rest of the world." (comma after "own"?)

On page 403 of the PDF, "file:" in "it could be a file: URL..." is not monospaced.

"The function dumpRDF() can be called anytime after the source has finished loading" ("anytime" -> "any time" or perhaps "at any point after")

No problems worth reporting that I could find! :)

Saying "<tree> can do everything <listbox> can do and more" is not really accurate: listboxes can hold arbitrary XUL content, while trees are pretty much restricted to text labels and an image.

"See the "AOM and XPCOM Interfaces" section for a discussion of JavaScript access..." (two spaces after "the")

'A value of "ascending" yeilds an up arrow.' ("ascending" should be monospaced)

"The remaining attributes apply to both single- and multicolumn listboxes." (should that be "multi-column", for consistency?)

For the entire chapter, but especially Table 13.6:

As indicated by bugs4hj@netscape.com on http://xulplanet.com/tutorials/xultu/treestyle.html

"Note: all mozilla builds dated 20030707 and later use a double-'::' notation for -moz-tree-* pseudo-elements."

At the start of 13.4.3:

"treetwity" -> "treetwisty"

"he default is don't care., which cannot be set explicitly." (excise period after "care")

"The <member> tag is free to apply a container test using the several predicate possibilities described earlier under "Ref and containment: Container Tests."

("Ref" should be "ref")

"Inside Mozilla, this template builder has a specialization (a subclass) that is specific to templated trees: the XUL tree builder." ("... trees, the XUL tree builder:" ?)

(I probably missed a bit for these next three chapters ... I glazed over and burned out, and kinda rushed the rest.)

"Postscript allows chunks of displayable content to be named and reused."

(Should probably be PostScript)

"Component names in the XBL system are URLs of the form Resource#Id, where Resource is a document's Web address and id is the value of the id attribute for a <binding> tag." (mismatch between "Id" and "id")

16.2.5.4: "After a file is located and represented internally by an object, it's usual to read, write, or manipulate that file." (the "it's" just seems a little awkward. Perhaps better expressed as "After being located and given an internal representation, files may be read from, written to, or manipulated." or "Files may be ... after ....")

I believe that "RS232" should be "RS-232"

Instead of "{CLSID_APPDATA}\Mozilla\Profiles", wouldn't it be easier to say "%appdata%\Mozilla\Profiles" ?

'That is discussed next. (see "Stream Content Conversion.")

16.3.2.1: Stream Content Conversion'

(surely, you don't need to direct the reader to the next sentence? :P )

"the Netscape SignTool tool" ... somewhat awkward, could be better expressed as "Netscape's SignTool"

"A package is a set of files layed out using the standard chrome directory structure of content, skins, and locales."

(layed -> laid)

Above 17.2.1.2:

"The Linux kernel and some other products use even minor numbers to indicate a stable release, and odd minor numbers to indicate an in-progress work."

A very minor quibble, but the "even" could be initially parsed as an indication for emphasis, rather than of n%2==0. Putting odd before even would clear that ambiguity.

"[XPInstall] is best seen as a specialized download tool like an FTP client or WinAMP." (WinAMP is a jukebox app, not a download tool.)

Table 17.4: "installversion" should be "InstallVersion"

"A dirty trick, which has worked in the past, is to use the magic number 32 (hex 0x20) as an nsRegistryKey argument" (should that be "nsIRegistryKey" ? )

You list an errata point concerning "prefs.js/preferences.js" as under Chapter 2, but it's technically still in Chapter One.

Repeated use of "second last", so I presume it's intentional (vs. "second-to-last" or "second to last")

"Chapter 10 - Windows and Panes

p282, Section 8.2.6.1. In the first para., for "Figure 8.3" read "Figure 8.1"."

(should be in ch8, not ch10)

Under Chapter 14 errata, you list corrections to 14.8, but the actual listing to be corrected is 14.18

"it is reads ref="about:blank"."