289249 - Need to handle changes to XUL app component files

Status: RESOLVED WORKSFORME

(Toolkit Graveyard :: XULRunner, defect)

Description

[Darin Fisher]

Need to handle changes to XUL app component files

We may want to simply support .autoreg files in the xulapp directory to force
AutoRegister to run, or we may want to do something more fancy.  We might want
to blow away compreg.dat and xpti.dat as we do when extensions change since
AutoRegister tends to leave around data from old and non-existant components,
which can result in various oddities.

Comment 1

[Darin Fisher]

To fix this bug I was thinking of modifying CheckUpdateFile in nsXPComInit.cpp
to check for .autoreg files alongside every 'components' directory.  Sound good?

Comment 2

[Benjamin Smedberg]

Yes, that sounds righteous.

Comment 3

[Ben Turner (not reading bugmail, use the needinfo flag!)]

I've been bitten by this before! I'd like to fix this but I won't have time for probably another two weeks or so.

Comment 4

[Kenny YU (:kennyyu)]

May I know what the problem is exactly about? Any way to generate this scanerio?

Kenny.

Comment 5

[Benjamin Smedberg]

Build a XUL app. Change a component in that XUL app so that it requires re-registering.

Although my message over the last year has been "change the buildid", which forces re-registration, so I'm not sure it's a big deal.

Comment 6

[Kenny YU (:kennyyu)]

(In reply to comment #5)
> Build a XUL app. Change a component in that XUL app so that it requires
> re-registering.
> 

Sorry... is it possible to let me know what exactly are the "components" that possibly make such problem? 

Just wish to re-simulate it myself once again... :-)

Comment 7

[Tiziana Sellitto [:tiziana]]

Looking at old "good first bugs" I've seen this one is not touched for a while. 
Benjamin, do you thinks it should stay as "good first bugs", is it still valid?

Comment 8

[Benjamin Smedberg]

comprehensive was removed and this no longer tracks anything interesting.