XMLExtras: nsIXMLHttpRequest::Send for Synchronous read fails




18 years ago
16 years ago


(Reporter: Thomas Lendacky, Assigned: Heikki Toivonen (remove -bugzilla when emailing directly))



Firefox Tracking Flags

(Not tracked)



(1 attachment)



18 years ago
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.
Whiteboard: [fixinhand]
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?
Whiteboard: [fixinhand]

Comment 4

18 years ago
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

18 years ago
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.
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 !=

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...
Assignee: vidur → heikki


17 years ago
Blocks: 62399
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.
Keywords: patch

Comment 12

17 years ago
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 

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.
Target Milestone: mozilla0.9 → mozilla0.9.1
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Target Milestone: mozilla0.9.2 → mozilla0.9.3

Comment 14

17 years ago
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


17 years ago
Blocks: 96683


17 years ago
No longer blocks: 96683
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
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME


16 years ago
QA Contact: petersen → rakeshmishra
You need to log in before you can comment on or make changes to this bug.