Closed Bug 551813 Opened 14 years ago Closed 14 years ago

Add option to prevent caching of components and modules

Categories

(Core :: XPConnect, enhancement)

x86
Windows XP
enhancement
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 531886

People

(Reporter: morac, Unassigned)

References

Details

I'm finding that in the latest nightly trunk loads, if I make changes to a module or component file in an installed add-on, the changes are not picked up when I quit and restart Minefield.  The only way to get the module or component files to load again is to delete the XPC.mfl cache file (or compreg.dat and xpti.dat files and restart twice) any time I make a change.

I'm not sure if this is a bug or a designed change (I'm assuming the later), but it is now a major pain when trying to develop add-ons since every time I change something in a module or component, not only do I have to restart Minefield, but now I also have to delete the XPC.mfl cache file.

If this is a designed change, could a preference be added to prevent caching of component and module files?  Maybe something like nglayout.debug.disable_xpc_cache or nglayout.debug.disable_xpc_fastload?

If that's not possible could you have a preference that when set caused the XPC.mfl file to be deleted during shutdown?
I thought this was the case on opt builds always....  Did we actually change something here?
Component: XPCOM → XPConnect
QA Contact: xpcom → xpconnect
What's considered an "opt build"?   I'm fairly certain I never ran across this when testing older nightly builds (i.e. 3.7a2pre).
Pretty much anything you download is an opt build.
Probably a dupe of bug 531886. bug 511761 changed the behavior here.
Depends on: 531886
Yeah it's a dupe. I looked for an existing bug, but I searched for XPC.mfl, not XPC.mfasl so I never found the other big.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.