this way we can implement an minimal chrome registry for embedding, that doesn't support all the wacky skin- and locale-switching goodness of XUL.
r=waterson, sr=hyatt
from previous checkin but set intl.locale.matchOS=false by default.
This should remove the start regression. Will watch the tree and
back this patch if the regression comes back. In theory, this should
not happen)
UI locale and system locale when intl.locale.matchOS == true; Runtime
only behavior; won't write to disk. Fallback to default chrome locale when
matching langpacks are not installed.
Summary of changes:
- Removed old XBL form control cruft.
- Made nsOutlinerContentView accessible from content scripts.
- Created a new interface, nsIDOMNSXBLFormControl which exists to allow a
select element to have an outliner box object.
- Factored out nsChildIterator into its own file.
- Added support to the outliner content view for having option elements
directly inserted in the outliner.
- Cleaned up pixel/twip conversions in outliner.
- Added support for intrinsic width for outliner.
r=jag, sr=hyatt. Note that the new select widget is NOT turned on by
default.
for me on optimized and debug gcc2.96, rh7.1.
- Better failure codes from nsXULPrototypeScript::Deserialize.
- Call nsXULDocument::AbortFastLoads after nsXULPrototypeScript::Serialize
failure, instead of just nulling the FastLoad service's output stream.
- Expose nsXULDocument::AbortFastLoads via nsIXULPrototypeCache, for use from
nsChromeProtocolHandler.cpp. AbortFastLoads flushes the XUL cache now, for
good measure.
- The needless "Current" adjective in nsIFastLoadService attribute and method
names is no more.
- Add a do_GetFastLoadService() helper, to use CID instead of contractid, and
to let the compiler consolidate the static inline CID.
- Add "nglayout.debug.checksum_xul_fastload_file" pref so people can do without
the checksum verification step when reading a FastLoad file.
- Verify the FastLoad file checksum, by default. Also, cache it in the FastLoad
service so we don't recompute it when re-opening the FastLoad file as mailnews
and other top-levels start up. Fill the checksum cache in EndFastLoad, when
the last pseudo-concurrent top-level finishes loading.
My hope to compute the checksum while writing the FastLoad file ran afoul of
misordered writes. The old code to checksum the in-memory nsFastLoadHeader
also was broken on little endian platforms. Now all checksumming is done via
a separate read pass over the complete file, save for the header's checksum
field, which is summed as if it contained zero.
- Track and check FastLoad file dependencies. This required groveling with a
bunch of Necko interfaces in nsChromeProtocolHandler::NewChannel -- read it
and weep. Dependency checking, as well as checksum access and computation,
use better-factored nsIFastLoad{File,Read,Write}Control interfaces.
- nsBufferedStream::Seek wasn't flushing the buffer when seeking backward
within the buffer, but it must, because mCursor bounds the amount to write
if the buffer contains the end of file.
- Add an unbufferedStream readonly attribute to nsIStreamBufferAccess, so we
don't have to screw around with the bufferying layer when checksumming. Also
implement nsIStreamBufferAccess in nsBufferedOutputStream.
- nsISeekableOutputStream was bogus, based on a bad state I had put the
nsBufferedOutputStream code in on its way from being completely broken when
you seek backwards outside of the buffer. Removing this interface required
using nsIFastLoadFileIO in nsFastLoadFileWriter, and it also required careful
ordering of Close calls (the Reader must close after the Writer or Updater,
so that the Reader's underlying, unbuffered input stream can be read by
nsFastLoadFileWriter::Close to compute the checksum.
- Miscellaneous tab/indentation, comment typo, bracing, if( => if ( style,
nsnull vs. 0, useless variable elimination, tortured control flow,
AutoString instead of String, and gratuitous ; after nsISupportsUtils.h
macro call cleanups.
- Call nsXULDocument::AbortFastLoads after nsXULPrototypeScript::Serialize
failure, instead of just nulling the FastLoad service's output stream.
- Expose nsXULDocument::AbortFastLoads via nsIXULPrototypeCache, for use from
nsChromeProtocolHandler.cpp. AbortFastLoads flushes the XUL cache now, for
good measure.
- The needless "Current" adjective in nsIFastLoadService attribute and method
names is no more.
- Add a do_GetFastLoadService() helper, to use CID instead of contractid, and
to let the compiler consolidate the static inline CID.
- Add "nglayout.debug.checksum_xul_fastload_file" pref so people can do without
the checksum verification step when reading a FastLoad file.
- Verify the FastLoad file checksum, by default. Also, cache it in the FastLoad
service so we don't recompute it when re-opening the FastLoad file as mailnews
and other top-levels start up. Fill the checksum cache in EndFastLoad, when
the last pseudo-concurrent top-level finishes loading.
My hope to compute the checksum while writing the FastLoad file ran afoul of
misordered writes. The old code to checksum the in-memory nsFastLoadHeader
also was broken on little endian platforms. Now all checksumming is done via
a separate read pass over the complete file, save for the header's checksum
field, which is summed as if it contained zero.
- Track and check FastLoad file dependencies. This required groveling with a
bunch of Necko interfaces in nsChromeProtocolHandler::NewChannel -- read it
and weep. Dependency checking, as well as checksum access and computation,
use better-factored nsIFastLoad{File,Read,Write}Control interfaces.
- nsBufferedStream::Seek wasn't flushing the buffer when seeking backward
within the buffer, but it must, because mCursor bounds the amount to write
if the buffer contains the end of file.
- Add an unbufferedStream readonly attribute to nsIStreamBufferAccess, so we
don't have to screw around with the bufferying layer when checksumming. Also
implement nsIStreamBufferAccess in nsBufferedOutputStream.
- nsISeekableOutputStream was bogus, based on a bad state I had put the
nsBufferedOutputStream code in on its way from being completely broken when
you seek backwards outside of the buffer. Removing this interface required
using nsIFastLoadFileIO in nsFastLoadFileWriter, and it also required careful
ordering of Close calls (the Writer or Updater must close after the Reader,
so that the Reader's underlying, unbuffered input stream can be read by
nsFastLoadFileWriter::Close to compute the checksum.
- Miscellaneous tab/indentation, comment typo, bracing, if( => if ( style,
nsnull vs. 0, useless variable elimination, tortured control flow,
AutoString instead of String, and gratuitous ; after nsISupportsUtils.h
macro call cleanups.
This removes all call-sites I can currently fix. Tomorrow I'll try to get someone to checkin my changes to security/ and I'll get some help with the Netscape side of things.
nsString::GetUnicode()'s final death-blow will be dealt soon. Please keep this in mind as you add new code :-)
Revising nsIChannel to allow for overlapped i/o. This consists of three parts:
1. Factoring nsIChannel into a protocol specific part, the nsIChannel, and a socket specific, the nsITransport.
2. Derive the nsIChannel from a nsIRequest.
2. Changes the notification system from necko and the URILoader to pass the nsIRequest interface instead of nsIChannel interface.
This goal stems from wanting to be able to have active AsyncRead and AsyncWrite operations on nsSocketTransport.
This is desired because it would greatly simplify the task of maintaining persistent/reusable socket connections
for FTP, HTTP, and Imap (and potentially other protocols). The problem with the existing nsIChannel interface is
that it does not allow one to selectively suspend just one of the read or write operations while keeping the other active.
r=darin@netscape.comsr=rpotts@netscape.com
1. Factoring nsIChannel into a protocol specific part, the nsIChannel, and a socket specific, the nsITransport.
2. Derive the nsIChannel from a nsIRequest.
2. Changes the notification system from necko and the URILoader to pass the nsIRequest interface instead of nsIChannel interface.
This goal stems from wanting to be able to have active AsyncRead and AsyncWrite operations on nsSocketTransport.
This is desired because it would greatly simplify the task of maintaining persistent/reusable socket connections
for FTP, HTTP, and Imap (and potentially other protocols). The problem with the existing nsIChannel interface is
that it does not allow one to selectively suspend just one of the read or write operations while keeping the other active.
The full details of the change on written up in the netlib newsgroup.
r=darin@netscape.comsr=rpotts@netscape.com
alecf%netscape.com
henry.jia%sun.com
darin%netscape.com
blakeross%telocity.com
ben%netscape.com
hyatt%netscape.com
tao%netscape.com
jkeiser%netscape.com
sfraser%netscape.com
ccarlen%netscape.com
bryner%netscape.com
jaggernaut%netscape.com
dp%netscape.com
timeless%mac.com
pierre%netscape.com
pete%alphanumerica.com
dougt%netscape.com
sspitzer%netscape.com
gerv%gerv.net
brendan%mozilla.org
blizzard%redhat.com
pavlov%netscape.com
andreas.otte%primus-online.de
dbaron%fas.harvard.edu
scc%mozilla.org
anatoliya%netscape.com
waterson%netscape.com
jst%netscape.com
kandrot%netscape.com
valeski%netscape.com
shaver%mozilla.org
disttsc%bart.nl
rickg%netscape.com
pinkerton%netscape.com
mkaply%us.ibm.com
gagan%netscape.com
dr%netscape.com
warren%netscape.com
mstoltz%netscape.com
pnunn%netscape.com
rayw%netscape.com
vidur%netscape.com
mscott%netscape.com
racham%netscape.com
jtaylor%netscape.com