nsRDFXMLDataSource::Refresh() broken for remote (http://...) rdf



17 years ago
4 months ago


(Reporter: tingley, Assigned: waterson)



Firefox Tracking Flags

(Not tracked)




17 years ago
More good news!

scm@eds.org pointed out that XUL templates that build from datasources 
referenced via http:// url stopped working at some point -- the templates are 
built empty.  These loads are being done asynchronously (as confirmed by 
checking the nsRDFXMLDataSource:5 log), as opposed to the blocking loads used 
by rdfcat (bug 89446) that have been broken for some time.

I confirmed this on linux; it's probably on other platforms as well.

This is sort of funny, actually -- I've tried on several occasions to rewrite 
rdfcat using non-blocking Refresh() but haven't been successful.  My most 
recent attempt (a month or more ago) worked fine for file urls but failed for 
http urls.  I never understood why;  it was probably because of this bug.

Presumably the magic goo in Refresh + associated code is no longer holding 
things together.

Comment 1

17 years ago
It looks like this was fixed recently

Comment 2

17 years ago
really?  fascinating.  the tree i tried it with was a bit stale; i'll try it
with a fresher one.  perhaps all is right in the world after all.

Comment 3

17 years ago
Ok, the problem I was seeing was just that the web server was serving the rdf as
text/plain instead of text/xml (*sigh*).  So is there actually a bug here?  Or
should I just WFM it?

Comment 4

17 years ago
Apparently I hallucinated this whole thing while in some sort of frenzy.  Not
only does this work for me, I've also finally succeeded in making the async
rewrite of rdfcat work, which is further proof that there's no problem.  WFM.
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME

Comment 5

16 years ago
tever is not RDF QA anymore
QA Contact: tever → nobody


4 months ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.