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.
18 years ago
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.
18 years ago
Target Milestone: --- → mozilla0.9
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.
Status: NEW → ASSIGNED
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...
Assignee: vidur → heikki
Status: ASSIGNED → NEW
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.
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.
Target Milestone: mozilla0.9 → mozilla0.9.1
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Doesn't look like this is getting fixed before the freeze tonight. Pushing out a milestone. Please correct if I'm mistaken.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Target Milestone: mozilla0.9.7 → mozilla0.9.9
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.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.