Closed
Bug 1389778
Opened 7 years ago
Closed 7 years ago
startup cache doesn't recognize changed omni.ja
Categories
(Core :: XPCOM, enhancement)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: pubkeypin, Unassigned)
References
Details
After unpacking omni.ja, changing a file inside, creating a new (compressed zip) archive and saving it as omni.ja, the restarted firefox does not always executes the files of the new omni.ja, but uses a previous version. Deleting all files in "startupCache" of the used profile makes firefox use the current omni.ja files. Before using cached files, firefox should verify that they don't differ compared to the current version. I'm seeing this with firefox-57.0a1.en-US.linux-x86_64
Comment 1•7 years ago
|
||
We now have a number of bugs open against the startup cache behaviour, and it's not clear to me who can actually work on this stuff, but the abundance of smoke makes a fire seem pretty plausible. Ting or :glandium, can you take a look and/or delegate to someone else who can? Thank you!
Updated•7 years ago
|
Component: General → XPCOM
Product: Firefox → Core
Comment 2•7 years ago
|
||
This is the intended behavior. The startup cache is cleared when the buildid changes but to avoid a startup penalty we don't revalidate the files on every launch.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Flags: needinfo?(mh+mozilla)
Flags: needinfo?(janus926)
Resolution: --- → WONTFIX
Is there a setting to at least disable this startup cache thing? Currently I've to delete these files nearly thirty times a day by hand or external script. Setting browser.cache.disk.enable browser.cache.memory.enable browser.cache.offline.enable browser.cache.use_new_backend_temp to false doesn't help.
Comment 4•7 years ago
|
||
Offhand, it looks like running with MOZ_PURGE_CACHES=1 in your environment ought to work. The workflow described in comment 0 is a bit unusual, I'm not sure that we should be modifying a bunch of things to accommodate that.
Thanks Nathan, that seems to work. As I don't know what is usual, I thought this is the (only) workflow without having to rebuild everything.
Comment 6•7 years ago
|
||
(In reply to pubkeypin from comment #5) > Thanks Nathan, that seems to work. > > As I don't know what is usual, I thought this is the (only) workflow without > having to rebuild everything. If you work off a source tree, you can run ./mach build faster , which will only repackage frontend source files. See also https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Artifact_builds which provide a relatively straightforward way to make frontend-only changes to our JS/XUL/CSS code.
(In reply to :Gijs from comment #6) > If you work off a source tree, you can run ./mach build faster , which will > only repackage frontend source files. See also > https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/ > Build_Instructions/Artifact_builds which provide a relatively > straightforward way to make frontend-only changes to our JS/XUL/CSS code. Thanks Gijs for this and your comments before. I'll look into this, but up to now I was reluctant to clone the whole source tree to the local machine.
You need to log in
before you can comment on or make changes to this bug.
Description
•