Dead code in CNavDTD.cpp is causing htmlparser to depend on layout. CNavDTD::HandleKeyGen() calls result=theFormProcessor->ProvideContent(theFormType,theContent,theAttribute); I can't locate an implementation of ProvideContent in the current source for Mozilla. Is this code really used? Removing the include for nsIFormProcessor.h from CNavDTD.cpp will get rid of the dependency on layout. Remove the REQUIRES layout from makefile.win too.

if you remove the function, does the code still compile? This is great!

Using this HTML: <form METHOD="post" ACTION="http://example.com/secure/keygen/test.cgi" ENCTYPE="application/x-www-form-urlencoded"> <keygen NAME="randomkey" CHALLENGE="1234567890"> <input TYPE="text" NAME="Field1" VALUE="Default Text"> </form> I caught it in the debugger at: nsresult CNavDTD::HandleKeyGen(nsIParserNode* aNode) { nsresult result=NS_OK; Accessing the service failed: nsCOMPtr<nsIFormProcessor> theFormProcessor = do_GetService(kFormProcessorCID, &result); So the function never actually executes. We need to find someone who know what this FormProcessor is supposed to do. The component doesn't appear to be in Mozilla any more.

that would be Kevin Mccluskey. CCing him for input.

This is NOT deadcode!. The formprocessor is a service that is provided in Netscape commercial builds to implement keygen. Keygen must be supported in Netscape commercial builds.

Thanx Kevin. Marking INVALID.

Is there a formal IFDEF for indicating Netscape commercial support code? We can just IFDEF this KEYGEN stuff and break the dependency. What's the point in having Mozilla keep checking for a component that will never be there.

"Is there a formal IFDEF for indicating Netscape commercial support code?". The formprocessor was designed to be generic. If there needs to be additional processing during form submission it can be done by implementing the form processor service. The Netscape commercial build uses it to implement KEYGEN. Other vendors could use it to implement features which require interposing on form submission.

Currently the commercial Netscape build does not do a *special* build of Mozilla. Ideally we would isolate the small amount of code that handles of KEYGEN parsing in the DTD into a parsing service that can be called from the current DTD code.

If this is for form submission, how does it get called from the CNavDTD in the html parser? Is form submission being parsed and validated?

There are two parts implementing keygen. Form submission and Keygen tag tranformation into a combobox. The keygen generated combobox requires multiple keys which come from a security module in the commercial build. The NavDTD is getting the items for the combobox from the Form Processor (Which is a massive Kludge!). The rest of the FormProcessor is a generic service that interposes on form submission and in the case of the Netscape commerical build it does the right thing for KEYGEN. We could file a new bug to make the NAVDTD processing of unknown tag's pluggable so that the KEYGEN specific processing could be moved out of Mozilla.

I agree that catching a tag during parsing and substituting generated text on the fly is a massive kludge. Wouldn't this be better handled by letting the tag pass through the parser and then when the KEYGEN DOM node is created handle the key generation there?

Verified invalid