56518 - XMLExtras: nsIXMLHttpRequest::Send for Synchronous read fails

Status: RESOLVED WORKSFORME

(Core :: XML, defect, P3)

Description

[Thomas Lendacky]

From Bugzilla Helper:
User-Agent: Mozilla/4.72 [en] (WinNT; U)
BuildID:    2000091312

Using the XMLExtras component nsIXMLHttpRequest::Send interface for synchronous 
read support from C++ code fails.  The reason is that an XPConnect native call 
context does not exist and so a DOM script context cannot be obtained.  Without 
this, a DocShellTreeOwner cannot be obtained to perform the ShowModal function 
in order to provide the synchronous support.

Reproducible: Always
Steps to Reproduce:
 

Actual Results:  A valid return code is returned, however the read of the XML 
document does not occur.

Expected Results:  The XML document should be read and parsed before returning 
control to the calling program.

I have provided a diff to Heikki, Vidur, and Nisheeth that attempts to obtain a 
DOM script context from the JSRuntime if an XPConnect native call context is not 
present.  Awaiting feedback on whether it is a valid and good approach.  Also, 
since the modal support is provided by the nsIDocShellTreeOwner the synchronous 
read support can only be performed within a browser environment.

Comment 1

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Attachment: Patch from Tom

Comment 2

[Heikki Toivonen (remove -bugzilla when emailing directly)]

I attached the latest patch from Tom that should fix this problem.

I have checked in a test program from Tom to xmlextras/tests so it is easier to
test this patch.

Comment 3

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Tom, this patch does not seem to work for me nor for anyone who has tried it.
Could you check that this really is the patch that it should be? Does it work
for you in the command line test program?

Comment 4

[Thomas Lendacky]

The patch will not work from within the command line test program.  In the 
original note that I sent along with the patch I stated the following:

"I've managed to come up with a way to get the Synchronous Read support to work.    
However, it only works from within the browser environment, it will not work 
using my test program that I sent.  The reason for this has to do with getting a 
DOM script context and also needing a DocShell in order to do the 
modal processing."

Since the test program does not create or have a DocShell, and therefore a 
Window - which is what actually performs the modal loop, you won't be able to 
test it with the command line program.

If you want to support Synchronous Read support in any environment, then the 
XMLExtras component will have to do the modal processing in some way.

Comment 5

[Thomas Lendacky]

If you want to test the patch (in the browser environment), then you will need 
code to get control when there is no XPConnect environment.  You could create an 
observer for Form Submissions (this is actually what my code is doing) and then 
have some test HTML that has a submit button.  The observer will get control and 
you can attempt to perform a synchronous read to test the patch.

Comment 6

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Tom, do you have a sample available that shows how to test your patch? I could
also check the sample into the tests directory.

Comment 7

[Heikki Toivonen (remove -bugzilla when emailing directly)]

I have the samples, thanks Tom. I'll try to move forward with this ASAP.

Comment 8

[Heikki Toivonen (remove -bugzilla when emailing directly)]

It still does not work for me, even with the test service. With the patch
applied, it gets stuck in

              rv = pXMLHttpRequest->Send( nsnull );

(the program is still running, it is just that this Send call doesn't return as
it is waiting in the "modal" event loop. I can use the application fine. Closing
the window produces a crash, though.

The strange thing is, if I do NOT apply the patch, the above call succeeds, and
document is fetched & parsed. GetResponseXML() fails though, because status !=
XML_HTTP_REQUEST_COMPLETED.

I will do some more investigation/testing to see what is happening.

Eventually I think we must provide a way to use this even from the command line.
The Mozilla Platform really needs a light weight way of handling XML data.

Comment 9

[Heikki Toivonen (remove -bugzilla when emailing directly)]

It seems the problem is with stylesheets: an XML document without stylesheet
works great with the patch. Adding a stylesheet prevents Send from returning.

Comment 10

[Heikki Toivonen (remove -bugzilla when emailing directly)]

I am taking all XMLExtras bugs to make it easier to see what I am working on...

Comment 11

[Heikki Toivonen (remove -bugzilla when emailing directly)]

I believe it should be possible to change the P3P implementation to use async
Send so this is not strictly a blocker for bug 62399 in my opinion.

Comment 12

[Thomas Lendacky]

The synchronous read is used for form submission support which needs to be able 
to read in the XML data (and make a decision) before allowing the form 
submission to proceed.  I suppose the modal loop can be done by P3P itself while 
waiting for an asynchronous read to complete.  However, you are then adding a 
bunch of extra complexity that should remain in the XMLExtras component so that 
any component that wants to do a synchronous read does not have to duplicate the 
effort.

Take a look and see if an additional parameter(s) (that can only be supplied by 
a native component, not by javascript) would provide you with the data you would 
need to perform the modal loop.  I'd be glad to try and work with you to see if 
I can gain access to any data that could help.

Comment 13

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Moving to the next milestone, but there is not really a high demand for sync
loading (sync loading and dialogs also cause problems). Might even future after
further analysis. You should be fine with async loading.

Comment 14

[Blake Ross]

Doesn't look like this is getting fixed before the freeze tonight.
Pushing out a milestone.  Please correct if I'm mistaken.

Comment 15

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Both SOAP and WSDL seem to be using sync load without problems. To test, compile
SOAP and open soapunscramble.html (in xmlextras/tests). I suspect this has
started working partly due to embedding work, but I am not completely sure
when/how/why the native context now exists so we can use it. Anyway, marking as
worksforme.