36038 - XSL code in mozilla doesn't call transformiix module

Status: VERIFIED FIXED

(Core :: XSLT, defect, P3)

Description

[Peter Van der Beken]

This is an ongoing issue. I'm trying to get transformiix integrated into 
Mozilla. I'm having trouble to make it call the transformiix module. To try this 
out you have to compile Mozilla with XSL defined and compile transformiix. This 
is on MacOS, i have no way of trying it out on another platform.

Reproducibility:
Every time.

Steps to reproduce
1. Compile Mozilla with XSL defined. (You'll have to add two files to 
layout.mcp: mozilla/layout/xsl/document/src/nsTransformMediator.cpp and 
nsXSLContentSink.cpp, and one file to layoutIDL.mcp: 
nsIDocumentTransformer.idl). You have to build transformiix and put the module 
into the Components folder of Mozilla. I'll add the Mac projects for 
transformiix later today.
2. Set a breakpoint in mozilla/layout/xsl/document/src/nsXSLContentSink.cpp at 
line 92 and in mozilla/layout/xsl/document/src/nsTransformMediator.cpp at line 
110.
3. Load mozilla/layout/xsl/tests/book.xml

Actual Results
You'll get two assertions (Since today 17/4 you only get the first), run past 
them:
###!!! ASSERTION: Error: Parser's IStreamListener API was not setup
correctly in constructor.: '(eNone==mParserContext->mStreamListenerState)', file 
nsParser.cpp, line 1376

###!!! ASSERTION: no mime type set: 'Not Reached', file CParserContext.cpp, line 
143

The breakpoint in nsXSLContentSink.cpp is not reached, the one in 
nsTransformMediator.cpp is but it never gets to line 114 because mStyleDOM is 
allways NULL. The XML document is loaded correctly, but the transformation is 
not tried.

Expected Results
Mozilla should try to call the transformiix module (at line 114 in 
nsTransformMediator.cpp) to transform the XML document. Line 92 in 
nsXSLContentSink.cpp should be called when the XSL document has been parsed and 
build.

Additional Information
I'm trying to track this down further, i understand the issue is quite vague 
right now. AFAICT the problem is that the XSL stylesheet is not loaded and 
parsed correctly.
One thing that seems to be a problem is the mime information for the XSL 
stylesheet. First of all, the mime type for book.xsl is set to text/plain. I 
tried adding a mapping in my Internet Config settings for .xsl to text/xsl but 
the type is still set to text/plain. This info was gathered with a breakpoint in 
nsMIMEService::GetTypeFromFile -- you'll have lots of breaks, but eventually one 
will be for the XSL document. I don't know (yet) how to solve this.

I also think there should be a change in mozilla/htmlparser/src/
CParserContext.cpp  in function CParserContext::SetMimeType(), namely adding 
this at line 143:

  else if(mMimeType.EqualsWithConversion(kXSLTextContentType))
    mDocType=eXMLText;

and this to mozilla/htmlparser/src/nsIParser.h at line 293:

#define kXSLTextContentType   "text/xsl"

As this hasn't solved the problem, i'm not completely sure these changes are 
needed, but they seem logical.

I've set this to module layout, but the mime problems are probably networking.

Sorry for the length of this report, i'm trying to get as much information as 
possible to you.

Comment 1

[Peter Van der Beken]

Well, i'm not so convinced anymore it's a mime problem.
The first ASSERTION seems to signal the problem, so here's the output of "how" 
and "sc" from MacsBug:

User break at 0D6306C4 dprintf(const char*, ...)+0008C
 ###!!! ASSERTION: Error: Parser's IStreamListener API was not setup correctly 
in constructor
.: '(eNone==mParserContext->mStreamListenerState)', file nsParser.cpp, line 1296

Calling chain using A6/R1 links
 Back chain  ISA  Caller
 00000000    PPC  0D79154C  
 0E36B4C0    PPC  0D77C2DC  main+001E0
 0E36B430    PPC  0D77A92C  main1(int, char**, nsISplashScreen*)+00748
 0E36B340    PPC  0D4DDA80  nsAppShellService::Run()+00054
 0E36B2F0    PPC  0D48CE78  nsAppShell::Run()+00040
 0E36B2B0    PPC  0D48D728  nsMacMessagePump::DoMessagePump()+00044
 0E36B260    PPC  0D48DA98  nsMacMessagePump::DispatchEvent(int, EventRecord*)+
001B0
 0E36B210    PPC  0EFC21F4  Repeater::DoRepeaters(const EventRecord&)+0003C
 0E36B1C0    PPC  0D4664A0  nsMacNSPREventQueueHandler::RepeatAction(const 
EventRecord&)+00014
 0E36B180    PPC  0D46677C  nsMacNSPREventQueueHandler::ProcessPLEventQueue()+
00274
 0E36B0F0    PPC  0D653858  nsEventQueueImpl::ProcessPendingEvents()+00068
 0E36B080    PPC  0D6CA660  PL_ProcessPendingEvents+00084
 0E36B030    PPC  0D6CA7A4  PL_HandleEvent+00054
 0E36AFF0    PPC  0D214B90  nsStreamListenerEvent::HandlePLEvent(PLEvent*)+00050
 0E36AFB0    PPC  0D215D80  nsOnStartRequestEvent::HandleEvent()+000DC
 0E36AF60    PPC  0E5179D0  nsFileChannel::OnStartRequest(nsIChannel*, 
nsISupports*)+000AC
 0E36AF10    PPC  0CB74D2C  nsParser::OnStartRequest(nsIChannel*, nsISupports*)+
00040
 0E36AE20    PPC  0D630A98  nsDebug::PreCondition(const char*, const char*, 
const char*, int)+0002C
 0E36ADE0    PPC  0D6307C4  nsDebug::Assertion(const char*, const char*, const 
char*, int)+0005C

I also have a StdLog, let me know if you want it.

I'm not sure what to do next. Nisheeth, would you like me to check in the 
Codewarrior projects i'm using? I'd rather not check them in already because 
they're still gonna change a lot in the following days, but if you want to debug 
this on a Mac you'll need them. Anything else i can do to help you track this 
down?

Comment 2

[Nisheeth Ranjan]

I think its a good idea to have the Mac projects checked in.  Then I'll be able 
to help you out on the Mac.  Thanks!

Comment 3

[Peter Van der Beken]

The Codewarrior project is checked in. There's a little problem with the rint 
function you checked in yesterday, it gives "ambiguous access to overloaded 
function" when compiling. Once that's solved (can you do that?) you should be 
able to compile the module and see why it all fails on Mac. To be clear, the 
module is loaded, a new XSLTPorcessor is created when needed but 
TransformDocument is never called because the XSL code in Mozilla fails.
Thanks for your help in this.

Comment 4

[Keith Visco]

The rint stuff works fine under Linux. I think, however, we should do one of the 
following, wrap it with #ifdef WINDOWS, or scope it (make it a private method of 
NumberFunctionCall.cpp or perhaps a Math.cpp class). I can do this tonight when 
I get in.

Comment 5

[Andreas Otte]

I was able to build the transformiix module for mozilla on linux. Running
functions.xml I'm getting this:

###!!! ASSERTION: Error: Parser's IStreamListener API was not setup
correctly in constructor.:
'(eNone==mParserContext->mStreamListenerState)', file nsParser.cpp, line
1639
###!!! Break: at file nsParser.cpp, line 1639
Assertion failure: eXMLContentSinkState_InEpilog != mState, at
nsXMLContentSink.cpp:699

Looks like the same thing Peter experienced on the mac. Something really seems
to be wrong with the glue code I think. Does this work on windows?

Confirming the bug.

Comment 6

[Nisheeth Ranjan]

Transformiix does not build as a mozilla component on windows.  I think I got it 
to the point where I got everything in extensions/transformiix to compile, but 
then ran into linker errors.

How do we build Transformiix as a mozilla component on Unix?  I'll give that a 
shot and try to debug the glue code there.

Comment 7

[Peter Van der Beken]

Changing to our (new) component

Comment 8

[Andreas Otte]

I had to do some heavy changes on String <> DOMString to get it compiling and 
linking under unix. I'm absolutely not sure about this changes and need some 
advice on what's the intention with String and DOMString. 

Comment 9

[Axel Hecht]

Hi,
just checked in Makefile.ins and configure stuff to build the xpcom module.
Use:
ac_add_options --with-extensions=all,xml-rpc,transformiix
ac_add_options --enable-xsl
to build it, but watch out, the string stuff is still broken.
I wondered, as we don't share any object files between standalone and
the xpcom module, do we still need two string classes? Keith?

The windows build stuff is utterly out of date, could someone (nisheeth?)
look at that?

Thanx, and happy debugging

Axel

Comment 10

[Axel Hecht]

ld.so.1: ./mozilla-bin: fatal: relocation error: file
/tmp/build/dist/bin/components/libraptorhtml.so: symbol
NS_NewTransformMediator__FPP20nsITransformMediatorRC8nsString: referenced symbol
not found
Killed
That's the error I get, after building the XPCOM module.
See post in .xslt, patch to layout will be next

Axel

Comment 11

[Axel Hecht]

Attachment: patch for mozilla/layout to build with MOZ_XSL=1, got rid of header mess

Comment 12

[Andreas Otte]

The transformer is not called because the style content model is not there. It's
necessary as this comment from nsXMLContentSink.cpp says:

  // Enable the transform mediator. It will start the transform
  // as soon as it has enough state to do so.  The state needed is
  // the source content model, the style content model, the current
  // document, and an observer.  The XML and XSL content sinks provide
  // this state by calling the various setters on nsITransformMediator.

Searching why this is not happening I found that DidBuildModel in
nsXSLContentSink.cpp is never called. DidBuildModel is not called because we QI
the wrong parser in nsXMLContentSink::LoadXSLStyleSheet. After changing that I
crash in nsXSLContentSink::DidBuildModel because mDocElement is never set but
QIed. This is where I'm stuck. Who has to set the mDocElement in the
XSLContentSink and with what?

Comment 13

[Andreas Otte]

Attachment: Patch to call the right parser (I hope) ...

Comment 14

[Axel Hecht]

Hi,
looks like this is the problem related to the question about 
nsIDocumentTransformer I posted to .xslt.
We need to be clever about what kind of nsIDocument to create, if it is a
HTMLDocument or XML Document (or plain text, other mime types?).
Nisheeth, did you have an idea about this when specifying the interface?

Axel

Comment 15

[Peter Van der Beken]

Thanks Andreas for getting us on the right track here. If Mozilla has the right 
mime mapping for .xsl files, the transformiix module is getting called. But it 
seems that the xml document and the xsl document that are passed to transformiix 
are the same (namely the xml document). I'm too tired to look at it right now, 
but i think we're nearly there.

Comment 16

[Peter Van der Beken]

Attachment: Patch to make mozilla recognize .xsl files as text/xml

Comment 17

[Andreas Otte]

Yes, with that change transformiix is getting called, but then it dies with

Document::getDocumentElement - Mozilla Call not ok(80004005)

in transformiix/source/xml/dom/mozImpl/MozillaDocument.cpp
 

Comment 18

[Andreas Otte]

Correction: It is not dying, it continues to process the document, but we never
call the Observe method of the XMLContentSink. We have to call the Observe
method with the right document to start the layout process. This might be
related to Axels last comment.

Comment 19

[Peter Van der Beken]

Andreas, i have a lot of changes in my tree to get it working. I'm trying to get 
them in this weekend.

Comment 20

[Andreas Otte]

I'm getting Observe called now but in the layout process it dies with this
message:

###!!! ASSERTION: You can't dereference a NULL nsCOMPtr with operator->().:
'mRawPtr != 0', file ../../dist/include/nsCOMPtr.h, line 647
###!!! Break: at file ../../dist/include/nsCOMPtr.h, line 647

and this nice stacktrace:

#0  0x414c5269 in nsGfxScrollFrame::Init () at nsGfxScrollFrame.cpp:1286
#1  0x415c9b6a in nsCSSFrameConstructor::InitAndRestoreFrame ()
    at nsCSSFrameConstructor.cpp:5188
#2  0x415c81c1 in nsCSSFrameConstructor::BuildGfxScrollFrame ()
    at nsCSSFrameConstructor.cpp:5188
#3  0x415c7d2b in nsCSSFrameConstructor::BeginBuildingScrollFrame ()
    at nsCSSFrameConstructor.cpp:5188
#4  0x415c0c68 in nsCSSFrameConstructor::ConstructRootFrame ()
    at nsCSSFrameConstructor.cpp:3209
#5  0x41747814 in StyleSetImpl::ConstructRootFrame () at nsStyleSet.cpp:1037
#6  0x414a5b6f in PresShell::InitialReflow () at nsPresShell.cpp:1507
#7  0x4166031c in nsXMLContentSink::StartLayout () at nsXMLContentSink.cpp:1093
#8  0x4165bab1 in nsXMLContentSink::StartLayoutProcess ()
    at nsXMLContentSink.cpp:786
#9  0x4165bbab in nsXMLContentSink::Observe () at nsXMLContentSink.cpp:786
#10 0x41774e91 in nsTransformMediator::TryToTransform ()
    at nsTransformMediator.cpp:81
...

I guess the layout process needs a documenttype the XMLContentSink is currently
not delivering. Peter, can you provide me with some diffs prior to checking it
in so that I can see what I'm doing wrong?

Comment 21

[Axel Hecht]

Hi,
after the code cleanup, and fixing one Makefile.in due to Peters checkin, I was
able to build the module. I had to redo andreas' patch, though.
I definitly need some chat with peter on this, I get the following error when 
loading functions.xml

*** check number of frames in content area 
Document
file:///tmp/mozilla/extensions/transformiix/source/examples/functions.xml loaded
successfully
WARNING: not calling OnDataAvailable, file
/tmp/mozilla/netwerk/base/src/nsAsyncStreamListener.cpp, line 409
Document::getDocumentElement - Mozilla Call not ok(80004005)
###!!! ASSERTION: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed: '(!((rv) &
0x80000000))', file /tmp/mozilla/layout/xml/document/src/nsXMLDocument.cpp, line
812
###!!! Break: at file /tmp/mozilla/layout/xml/document/src/nsXMLDocument.cpp,
line 812
Segmentation Fault

This looks to come from HTML not being supported by nsXMLDocument (!?!)
    rv = NS_ERROR_NOT_IMPLEMENTED; //do we want html elements from here??
on line 804

Axel

Comment 22

[Axel Hecht]

Attachment: Updated patch by Andreas

Comment 23

[Peter Van der Beken]

Let's keep this bug report focused please. We have the two patches (the last 
two) that need to go in the tree to resolve this bug. After those patches, the 
XSL code in mozilla calls the transformiix module. Please file different bug 
reports for other problems, they're caused by other areas of the codebase and 
are entirely different bugs.

Comment 24

[Nisheeth Ranjan]

The fix for this is not going to affect the default Mozilla build.  I'm going to 
check this patch in today and close out this bug...

Comment 25

[Nisheeth Ranjan]

This is checked in.

Comment 26

[Chris Petersen]

Marking verified per last comments.