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.

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.

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?

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.

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.

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

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

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.

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

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

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.

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.

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.

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

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.