Closed Bug 10712 Opened 21 years ago Closed 21 years ago

[PP]RDFRemoteDataSource chokes on resource names with Windows file: URLs

Categories

(Core Graveyard :: RDF, defect, P3)

defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: dbaron, Assigned: waterson)

References

Details

Attachments

(5 files)

Test cases to be attached:
  * rdftest.html
  * rdftest.rdf (when you download it, keep this filename, and put the 2 in the
same directory)

Load rdftest.html, and you will see that RDFRemoteDataSource gives error
messages like this on Windows, but not Linux:

Browser Window Alert: Caught exception [[Component returned failure code: 0x8000
ffff [nsISimpleEnumerator.HasMoreElements, {file: file:///e|/rdftest.html, line:
 87}]]]

JavaScript error: uncaught exception: Component returned failure code: 0x8000fff
f [nsIRDFContainer.AppendElement, {file: file:///e|/rdftest.html, line: 108}]

The problem comes from changing the test case for bug 9236 to *correctly* use
RDF:Bag id="" rather than about="" so that the resource name (used for
GetResource()) includes a file: URL.  I think this could have something to do
with ":" or "|" in file: URLs or something like that, since it happens on
Windows but not Linux.

If this is confusing, I'm tired.  And a bit confused and disoriented from
working under a now-unfamiliar operating system.  Ask me tomorrow :-).

Fails on the following windows builds:
 * July 25 apprunner
 * July 27 apprunner
 * July 27 viewer.

I've yet to verify that the test case itself works on Linux (I will when I
reboot), but I've seen the more complex case work/fail for the same reasons
depending on platform.  (Bad sentence, but you know what I mean.)
Attached file rdftest.html
Attached file rdftest.rdf
Guess what?  That test case gives the exact same errors on Linux.

So now I've got to try and find something that works on Linux and fails on
windows.  But maybe the failing on Linux is a bug too...???
Status: NEW → ASSIGNED
Target Milestone: M9
Attached file bugtest.html
Attached file bugtest.rdf
The above tests (bugtest.*) work under Linux and fail in Windows.
Blocks: 11414
Move to M10.
This seems fixed in 1999-08-15-09-M9.
Assignee: waterson → phillip
Status: ASSIGNED → NEW
Since this seems fixed in 8/15 M9 .... Phillip, can you verify so we can
take this off of Waterson's list for M11?

Reassigning to Phillip.
Assignee: phillip → waterson
sorry, that's not how things are done around here. reassigning to waterson...
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
marking resolved fixed, since it is.

i'll verify when i get a stable linux build.
Status: RESOLVED → REOPENED
OS: Windows 95 → All
Hardware: PC → All
looks like we spoke too soon. this crashes all platforms:

1. choose either of the testcases above
2. in each case, the described alert appears, as it should not.
3. in each case, dismissing the alert crashes apprunner, as it should not.

this crash occurs on
     1999-09-14-09-M10 RedHat Linux 6.0 (GNOME/enlightenment)
     1999-09-14-09-M10 WinNT 4.0 sp5
     1999-09-14-09-M10 MacOS 8.51

reopening bug.
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
Closed: 21 years ago21 years ago
Resolution: --- → FIXED
Okay, some comments:

1. rdftest.html and rdftest.rdf are _not_ compatible. The HTML file expects the
root resource to be "WhenCOM:Something"; the RDF file incorrectly uses a
lower-case "id=" to specify a document-relative resource ID. So that test case
is INVALID.

2. If you SAVE THE FILES LOCALLY, this does _not_ crash; it asserts.

Using the second set of test cases (bugtest.html and bugtest.rdf) seems to work
JUST FINE.

If you attempt to load the files thru bugsplat THIS WILL NOT WORK.
Status: RESOLVED → VERIFIED
ok, my fault. i saved the files locally, but viewed them using http:// instead
of file://

sorry for all the noise, marking verified.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.