Empty sequence causes an exception on AppendElement

VERIFIED INVALID

Status

()

Core
RDF
--
major
VERIFIED INVALID
17 years ago
17 years ago

People

(Reporter: Eric Plaster, Assigned: Chris Waterson)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(7 attachments)

(Reporter)

Description

17 years ago
If you add nodes to the root sequence then delete them, restart mozilla, and try
to add a node again you get a exception:
JavaScript error:

 line 0: uncaught exception: [Exception... "Component returned failure code:
0x8000ffff (NS_ERROR_UNEXPECTED) [nsIRDFContainer.AppendElement]"  nsresult:
"0x8000ffff (NS_ERROR_UNEXPECTED)"  location: "JS frame ::
chrome://navigator/content/test.js :: test_Add :: line 67"  data: no]

I will attach a test case that shows this error in 0.8

I was not able to try this on different platforms.
(Reporter)

Comment 1

17 years ago
Created attachment 27257 [details]
File utilies from jslib.mozdev.org needed for this example
(Reporter)

Comment 2

17 years ago
Created attachment 27258 [details]
Test case javascript file
(Reporter)

Comment 3

17 years ago
Created attachment 27259 [details]
Xul file for test case
(Assignee)

Comment 4

17 years ago
Could you please attach the RDF/XML that's spit out after you've ``removed all 
the elements''?
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 5

17 years ago
Created attachment 27272 [details]
RDF file after the add node > remove node > restart cycle
(Assignee)

Comment 6

17 years ago
Oh, I see the problem. nsIRDFService::GetDataSource() is asynchronous. So the 
datasource isn't loaded by the time you want to start poking at it. Could you 
play around with some of the techniques described at

  http://www.mozilla.org/rdf/doc/faq.html#how_to_tell_if_rdfxml_loaded

Re-open the bug if I'm wrong.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → INVALID
(Reporter)

Comment 7

17 years ago
Created attachment 27278 [details]
Added the remote.loaded debug dump
(Reporter)

Comment 8

17 years ago
This isn't the case.  The test_Add() and test_Delete are called from the
'oncommand' callback of the buttons.  The datasource has plenty of time to read
it in.  I also added a check at the top of those functions to see if it is
loaded and it is.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
(Assignee)

Comment 9

17 years ago
No, this is still wrong. The problem is that you are inadvertently messing with 
the datasource while it is still loading. Move your container initialization 
(the RDFC.Init() cruft) into your oncommand callbacks.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → INVALID
(Reporter)

Comment 10

17 years ago
Created attachment 27362 [details]
** New test.js to with a setTimeout
(Reporter)

Comment 11

17 years ago
Created attachment 27363 [details]
** new test.xul that calls the RDFC.Init first
(Reporter)

Comment 12

17 years ago
I seperated the RDFC.Init() and the RDFC.AppendElement into seperate functions. 
The RDFC.Init() is called first and then I use a setTimeout(..., 4000); to call
the RDFC.AppendElement().  This still shows up.  I also added a check to see if
the datasource is loaded RIGHT before I call AppendElement and it tells me that
it IS loaded.  So the only thing that I am doing in the second function is
AppendElement.

I'm only trying to help here Chris.  If it is my code, then I need you to tell
me what it is.  Otherwise I think this is a valid bug.  If there is anything
that I can do to help, just let me know.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
(Assignee)

Comment 13

17 years ago
I know you're trying to help; I'm sorry, I'm not being clear here. This is the 
problem:

  // Get a reference to the available datasources
  //dump("getting data source: " + TEST_RDF_FILE + "\n");
  dsource = RDF.GetDataSource("file://"+TEST_RDF_FILE);

At this point, we schedule a load for ``dsource,'' but nothing will be loaded 
yet. But then you immediately do:

  try {
    // Initialize the RDF Container with the datasource and root node.
    // An error will occur if the datasource or root node does not exist
    // (for example, if the RDF file was not found).
    RDFC.Init(dsource, rootnode);
    return;
  } catch (ex) {}

The above code now looks for assertions in ``dsource'', trying to determine if 
``rootnode'' is a sequence! Since nothing will have loaded yet, this will always 
fail!

But now you've stifled the exception and you do:

  // If we got to this point, we need to create the root node ourselves
  RDFCUtils.MakeSeq(dsource,rootnode);
  RDFC.Init(dsource, rootnode);

You've now modified the datasource! And guess what, it hasn't even begun to load 
yet. So when the assertions from the RDF/XML actually start to get processed, 
who knows what state the datasource will actually be in!

What I'm suggesting is that, with your latest round of JS, *none* of this code 
is necessary. Just do RDF.GetDataSource() and get on with life! Then, in your 
test_AddInit() etc. routines, check

  dsource.QueryInterface(Components.interfaces.nsIRDFRemoteDataSource).loaded

and bail early if it's not ``true''. (In other words, the datasource hasn't 
finished loading yet: you'll just have to wait.)

For a ``real application'', there are better ways to observe the load than 
polling the ``loaded'' attribute, but let's just get on the same page, first.
(Reporter)

Comment 14

17 years ago
You're right we weren't on the same page.  I was thinking there was a problem on
the adding of the nodes, and here it was in my initialization code.  The thing
was, I snarfed that code from mozilla sometime around M18-M19 (I can't remember
where, and it really doesn't matter anymore).  I just assumed it always worked,
and figured it was the code that I wrote.

I apologize for taking up your time, when I'm sure you have just as tight (if
not tighter) deadlines than I.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → INVALID

Comment 15

17 years ago
verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.