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.
To fix this bug I was thinking of modifying CheckUpdateFile in nsXPComInit.cpp to check for .autoreg files alongside every 'components' directory. Sound good?
Yes, that sounds righteous.
Whiteboard: [good first bug]
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.
May I know what the problem is exactly about? Any way to generate this scanerio? Kenny.
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.
(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... :-)
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?
comprehensive was removed and this no longer tracks anything interesting.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
Product: Toolkit → Toolkit Graveyard
You need to log in before you can comment on or make changes to this bug.