The ``rdfcat'' test program appears to work correctly with ``file:'' URLs, but not with ``http:'' URLs. It's possible that it's not driving Necko correctly anymore. Needs investigation...
Status: NEW → ASSIGNED
Keywords: qawanted, regression
Priority: -- → P4
Target Milestone: --- → mozilla1.0
It seems that rdfcat is broken for remote URLs because nsHttpChannel::Open() is unimplemented -- only AsyncOpen() is supported. Sincerdfcat doesn't work with ``http:'' URLs RDFXMLDataSourceImpl::BlockingParse() returns NS_OK when it can't open the channel, the failure is silent... http://lxr.mozilla.org/seamonkey/source/rdf/base/src/nsRDFXMLDataSource.cpp#546 http://lxr.mozilla.org/seamonkey/source/netwerk/protocol/http/src/nsHttpChannel.cpp#1816 I think this broke when the HTTP branch landed in May. This should probably be sent to Networking, but since it's assigned I'll leave that for waterson.
That comment got messed up. The first paragraph should have read: It seems that rdfcat is broken for remote URLs because nsHttpChannel::Open() is unimplemented -- only AsyncOpen() is supported. Since RDFXMLDataSourceImpl::BlockingParse() returns NS_OK when it can't open the channel, the failure is silent...
darin: What happened to that wrapper class for Open using asyncopen? threadsafety isn't a problem here.
i don't want to include a broken non-threadsafe nsHttpChannel::Open implementation. however, that being said.. we are pretty close to being able to implement Open correctly.. there just hasn't been any need (until now). bbaetz: i still have that wrapper implementation in my mailbox.
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
Created attachment 61811 [details] [diff] [review] fix Rewritten to use non-blocking Refresh() and pump an event queue until the datasource loads. I also corrected the bogus usage and macroized the failure messages. The event pumping will generate lots of thread-safety assertions (it looks like 1 per call to ProcessPendingEvents()) for the nsNativeComponentManager, but since these also occur with the network TestFileTransport app, I wasn't going to worry about them.
Created attachment 62362 [details] [diff] [review] v2 clean diff after dbaron's NS_SetupRegistry changes.
Attachment #61811 - Attachment is obsolete: true
Comment on attachment 62362 [details] [diff] [review] v2 sr=waterson
Attachment #62362 - Flags: superreview+
rjc, can you review? thanks.
Comment on attachment 62362 [details] [diff] [review] v2 Sure, r=rjc
Attachment #62362 - Flags: review+
fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
tever is not RDF QA anymore
QA Contact: tever → nobody
You need to log in before you can comment on or make changes to this bug.