Open Bug 68306 Opened 24 years ago Updated 6 years ago

Trees with remote RDF need to be rebuild in order to display correct data

Categories

(Core Graveyard :: RDF, defect)

x86
Windows 98
defect
Not set
normal

Tracking

(Not tracked)

Future

People

(Reporter: mik, Unassigned)

Details

Attachments

(3 files)

Trees with remote RDF need to be rebuild in order to display correct data. This means that when having a tree with remote datasource (HTTP, in particuluar), attached to it, it is required to do tree.builder.rebuild in order to show correct data. In the attached case server return a little different tree each time, and clicking reload button one can see empty lines in the tree. Looks like during the reloading tree display correct data, but when reloading ends it draws empty lines. Build ID: 2001020820
Attached file JS part of a test-case (deleted) —
Attached file A bit more correct testcase JS (deleted) —
I discovered the reason for such a behaviour: Let's assume we have and RDF resource where titles of an items are changing. So, titles are connected to nodes via assertion ....#title When doing refresh of source nsIRDFRemoteDataSource issues a set of modification on a data source. The problem is in the order of assertions/unassertions. Now, datasource first asserts new title, and then unasserts old one. So, tree first displays new value, but then it receives unassert notification and _removes_ corresponding line. The first solution here can be to change the order of modification -- do unassert first, and assert after. Secound solution can be to do change instead of assert/unassert.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → mozilla1.0
That sounds plausable. The relevant code is in nsInMemoryDataSource::Mark() and nsInMemoryDataSource::Sweep(), if you want to beat me to looking at the bug. ;-)
...actually, thinking about it a bit more, I bet this is a bug with nsXULTemplateBuilder.cpp. It should know better. (Ideally the nsInMemoryDataSource would issue OnChange() notifications in the case you describe, but the template builder shouldn't fall over if it doesn't get 'em that way...)
Well, tis is acrtually two issues -- yes, trees should behave OK with such a changes in the datasource, but also yes, datasource should do Change in such a situation. Both issues are very important for Mozilla The Platform. BTW, making tree understand such a situations is not so easy. Here we have a time terion when TWO titles exist at the same time, and this is OK from the datasource point of view. What should tree do when it deals with two titles?
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
Target Milestone: mozilla1.0.1 → Future
Looks like new tree (outliner) behaves well without rebuild. I'll try to check better this and also how <listbox> behaves.
Ops... This is still the case with both <outliner> and <listbox>. It's still an issue...
tever is not RDF QA anymore
QA Contact: tever → nobody
waterson left the building
Assignee: waterson → nobody
Status: ASSIGNED → NEW
QA Contact: nobody → core.rdf
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: