parser/htmlparser - mozsearch

firefox-main/parser/htmlparser

	Name	Description	Size	Coverage
	CParserContext.cpp		1865	100 %
	CParserContext.h	MODULE NOTES: @update gess 4/1/98	1640	-
	metrics.yaml		2259	-
	moz.build		1184	-
	nsElementTable.cpp		6999	100 %
	nsElementTable.h		466	-
	nsExpatDriver.cpp	RLBOX HELPERS *******************************	64981	96 %
	nsExpatDriver.h	Pass a buffer to Expat. If Expat is blocked aBuffer should be null and aLength should be 0. The result of the call will be stored in mInternalState. Expat will parse as much of the buffer as it can and store the rest in its internal buffer. @param aBuffer the buffer to pass to Expat. May be null. @param aLength the length of the buffer to pass to Expat (in number of char16_t's). Must be 0 if aBuffer is null and > 0 if aBuffer is not null. @param aIsFinal whether this is the last chunk in a row passed to ParseChunk, and if so whether it's the last chunk and buffer passed to ParseChunk (meaning there will be no more calls to ParseChunk for the document being parsed). @param aConsumed [out] the number of PRUnichars that Expat consumed. This doesn't include the PRUnichars that Expat stored in its buffer but didn't parse yet. @param aLastLineLength [out] the length of the last line that Expat has consumed. This will only be computed if aIsFinal is not None or mInternalState is set to a failure.	10949	100 %
	nsHTMLTagList.inc	This file contains the list of all HTML tags. See nsHTMLTags.h for access to the enum values for tags. It is designed to be used as input to various places that will define the HTML_TAG macro in useful ways through the magic of C preprocessing. Additionally, it is consumed by the self-regeneration code in ElementName.java from which nsHtml5ElementName.cpp/h is translated. See parser/html/java/README.txt. If you edit this list, you need to re-run ElementName.java self-regeneration and the HTML parser Java to C++ translation. All entries must be enclosed in the macro HTML_TAG which will have cruel and unusual things done to it. It is recommended (but not strictly necessary) to keep all entries in alphabetical order. The first argument to HTML_TAG is the tag name. The second argument is the "creator" method of the form NS_New$TAGNAMEElement, that will be used by HTMLElementFactory.cpp to create a content object for a tag of that type. Use NOTUSED, if the particular tag has a non-standard creator. The third argument is the interface name specified for this element in the HTML specification. It can be empty if the relevant interface name is "HTMLElement". The HTML_OTHER macro is for values in the nsHTMLTag enum that are not strictly tags. Entries must use only lowercase characters. Don't forget to update /editor/libeditor/HTMLEditUtils.cpp as well. * Break these invariants and bad things will happen. **	6389	-
	nsHTMLTags.cpp		4624	100 %
	nsHTMLTags.h	Declare the enum list using the magic of preprocessing enum values are "eHTMLTag_foo" (where foo is the tag) To change the list of tags, see nsHTMLTagList.inc These enum values are used as the index of array in various places. If we change the structure of the enum by adding entries to it or removing entries from it _directly_, not via nsHTMLTagList.inc, don't forget to update dom/bindings/BindingUtils.cpp and dom/html/HTMLElementFactory.cpp as well.	2564	100 %
	nsIContentSink.h	MODULE NOTES: @update gess 4/1/98 This pure virtual interface is used as the "glue" that connects the parsing process to the content model construction process. The icontentsink interface is a very lightweight wrapper that represents the content-sink model building process. There is another one that you may care about more, which is the IHTMLContentSink interface. (See that file for details).	4133	29 %
	nsIExpatSink.idl	This interface should be implemented by any content sink that wants to get output from expat and do something with it; in other words, by any sink that handles some sort of XML dialect.	4445	-
	nsIFragmentContentSink.h	The fragment sink allows a client to parse a fragment of sink, possibly surrounded in context. Also see nsParser::ParseFragment(). Note: once you've parsed a fragment, the fragment sink must be re-set on the parser in order to parse another fragment.	2610	-
	nsIParser.h	This GECKO-INTERNAL interface is on track to being REMOVED (or refactored to the point of being near-unrecognizable). Please DO NOT #include this file in comm-central code, in your XULRunner app or binary extensions. Please DO NOT #include this into new files even inside Gecko. It is more likely than not that #including this header is the wrong thing to do.	6005	-
	nsParser.cpp	The parser can be explicitly interrupted by passing a return value of NS_ERROR_HTMLPARSER_INTERRUPTED from BuildModel on the DTD. This will cause the parser to stop processing and allow the application to return to the event loop. The data which was left at the time of interruption will be processed the next time OnDataAvailable is called. If the parser has received its final chunk of data then OnDataAvailable will no longer be called by the networking module, so the parser will schedule a nsParserContinueEvent which will call the parser to process the remaining data after returning to the event loop. If the parser is interrupted while processing the remaining data it will schedule another ParseContinueEvent. The processing of data followed by scheduling of the continue events will proceed until either: 1) All of the remaining data can be processed without interrupting 2) The parser has been cancelled. The nsContentSink records the time when the chunk has started processing and will return NS_ERROR_HTMLPARSER_INTERRUPTED if the token processing time has exceeded a threshold called max tokenizing processing time. This allows the content sink to limit how much data is processed in a single chunk which in turn gates how much time is spent away from the event loop. Processing smaller chunks of data also reduces the time spent in subsequent reflows. This capability is most apparent when loading large documents. If the maximum token processing time is set small enough the application will remain responsive during document load. A side-effect of this capability is that document load is not complete when the last chunk of data is passed to OnDataAvailable since the parser may have been interrupted when the last chunk of data arrived. The document is complete when all of the document has been tokenized and there aren't any pending nsParserContinueEvents. This can cause problems if the application assumes that it can monitor the load requests to determine when the document load has been completed. This is what happens in Mozilla. The document is considered completely loaded when all of the load requests have been satisfied. Currently the parser is ignores requests to be interrupted during the processing of script. This is because a document.write followed by JavaScript calls to manipulate the DOM may fail if the parser was interrupted during the document.write. For more details @see bugzilla bug 76722	36371	88 %
	nsParser.h	MODULE NOTES: This class does two primary jobs: 1) It iterates the tokens provided during the tokenization process, identifing where elements begin and end (doing validation and normalization). 2) It controls and coordinates with an instance of the IContentSink interface, to coordinate the the production of the content model. The basic operation of this class assumes that an HTML document is non-normalized. Therefore, we don't process the document in a normalized way. Don't bother to look for methods like: doHead() or doBody(). Instead, in order to be backward compatible, we must scan the set of tokens and perform this basic set of operations: 1) Determine the token type (easy, since the tokens know) 2) Determine the appropriate section of the HTML document each token belongs in (HTML,HEAD,BODY,FRAMESET). 3) Insert content into our document (via the sink) into the correct section. 4) In the case of tags that belong in the BODY, we must ensure that our underlying document state reflects the appropriate context for our tag. For example,if we see a <TR>, we must ensure our document contains a table into which the row can be placed. This may result in "implicit containers" created to ensure a well-formed document.	9014	71 %
	nsParserBase.h		472	0 %
	nsParserConstants.h		647	-
	nsParserMsgUtils.cpp		1870	100 %
	nsParserMsgUtils.h		1030	-
	nsRLBoxExpatDriver.h		827	100 %
	nsScanner.cpp	Use this constructor if you want i/o to be based on a single string you hand in during construction. This short cut was added for Javascript. @update gess 5/12/98 @param aMode represents the parser mode (nav, other) @return	9256	70 %
	nsScanner.h	MODULE NOTES: @update gess 4/1/98 The scanner is a low-level service class that knows how to consume characters out of an (internal) stream. This class also offers a series of utility methods that most tokenizers want, such as readUntil() and SkipWhitespace().	5145	100 %
	nsScannerString.cpp	nsScannerBufferList	11248	65 %
	nsScannerString.h	NOTE: nsScannerString (and the other classes defined in this file) are not related to nsAString or any of the other xpcom/string classes. nsScannerString is based on the nsSlidingString implementation that used to live in xpcom/string. Now that nsAString is limited to representing only single fragment strings, nsSlidingString can no longer be used. An advantage to this design is that it does not employ any virtual functions. This file uses SCC-style indenting in deference to the nsSlidingString code from which this code is derived ;-)	13593	93 %
<1%	tests			-

Revision control

Other Tools