Cached RDF data sources go boom

[GoogleCodeExporter]

Reported by Sakuya, and finally confirmed by me on my G5 running Classic,
but does not affect the build G4 or PB 1400. Although helper apps are
maintained and operate correctly, the pref panel does not populate its
list. The entries are there, however, because it won't let you overwrite
them even though they are not shown.

Regression from 9.0.4.

Original issue reported on code.google.com by classi...@floodgap.com on 9 Mar 2010 at 4:44

• Blocked on: #1

[GoogleCodeExporter]

Virgin profiles do it too, so now I have a test case.

Original comment by classi...@floodgap.com on 24 May 2010 at 4:29

[GoogleCodeExporter]

Switching profiles also does it, but only the first time. The second time, the 
types
appear normally.

I have replaced mimeTypes.rdf with a sample set in profile/ just in case, but 
the
change in behaviour is puzzling.

Original comment by classi...@floodgap.com on 24 May 2010 at 5:18

• Changed title: mimeTypes.rdf doesn't stay in sync

[GoogleCodeExporter]

New profiles seem fixed by this change. I'm going to leave this marked as high, 
but
at least we have a workaround.

Original comment by classi...@floodgap.com on 30 May 2010 at 10:19

[GoogleCodeExporter]

We do *not* have a workaround. It doesn't stick that way either.

Guard code in the pref panel shows that the RDF doesn't feed it any data. IOW, 
on
affected profiles, the xmlSinkObserver's onBeginLoad never fires, only 
onEndLoad. On
working profiles, both fire.

Original comment by classi...@floodgap.com on 4 Jun 2010 at 3:57

[GoogleCodeExporter]

The RDF service thought that mimeTypes.rdf was already loaded. Turns out that
Classilla builds defective profiles. Besides having an out of date 
mimeTypes.rdf,
there is no downloads.rdf, and for some reason when it is missing then the rest 
poop
out. This *was* created by WaMCom, so ironically WaMCom profiles have no 
problems.
Added downloads.rdf to the profile defaults and created a new profile, and it 
seems
to work.

Leaving this bug open, just in case.

Original comment by classi...@floodgap.com on 4 Jun 2010 at 5:29

[GoogleCodeExporter]

Original comment by classi...@floodgap.com on 4 Jun 2010 at 5:30

• Changed title: New profiles are missing components [was: Helper applications don't show]

[GoogleCodeExporter]

... and it seems to work ONLY because if you right to it as the app opens, then 
you
get the helper apps. If you do anything else or go anywhere else in 
preferences, you
don't.

Tracing shows that when the RDF gets cached, it goes boom. Disabling the RDF 
cache,
however, is a major performance hit.

The combination of new profile and restarting the browser (or switching 
profiles back
and forth) lets you get at this and it seems so far that Helper apps are the 
only
ones affected. I'm shipping with this bug and the workaround. Earlier 
Classillas do
it too. I'm not sure why it wasn't noticed earlier, so clearing the Regression 
flag.

Original comment by classi...@floodgap.com on 4 Jun 2010 at 3:55

• Changed title: Cached RDF data sources go boom
• Removed labels: Regression

[GoogleCodeExporter]

Reliable workaround:

- Make sure the desired profile has a downloads.rdf (or copy it from a new 
profile).
- Create a second dummy profile.
- Start with the desired profile.
- Immediately go to Preferences > Navigator > Helper Applications. They should 
all
show up.

To edit the helper apps, switch to the dummy profile, then switch back, then go
immediately to preferences.

This sucks, but it seems to work.

Original comment by classi...@floodgap.com on 4 Jun 2010 at 5:22

[GoogleCodeExporter]

Perhaps we can just disable the cache for the helper datasource. This is not 
nice but probably simplest.

Original comment by classi...@floodgap.com on 6 Feb 2011 at 7:49

[GoogleCodeExporter]

M58811 implies that this is fixed in DOM. Marking dependent on issue 1.

Original comment by classi...@floodgap.com on 6 Feb 2011 at 11:46