Closed Bug 1389778 Opened 7 years ago Closed 7 years ago

startup cache doesn't recognize changed omni.ja

Categories

(Core :: XPCOM, enhancement)

57 Branch
x86_64
Linux
enhancement
Not set
normal

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
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!
Flags: needinfo?(mh+mozilla)
Flags: needinfo?(janus926)
See Also: → 1368699, 1364235
Component: General → XPCOM
Product: Firefox → Core
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.
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.
(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.