provide programmatic way of clearing cache

[gruehle]

Right now, file:// urls get cached by the shell. This means that if an end user installs/updates an extension and reloads, they won't see the new version.

We need a way to programmatically clear the cache. Ideally, this could be initiated from JavaScript.

Right now it seems that the caching is only in effect for the currently running instance of brackets-shell. It does not seem to cache across launches. (I.e. completely restarting solves the problem.) However, there's only anecdotal evidence on the Mac to support this. We should verify that this will always be true (on all platforms) if we want to use re-launching as a solution to the problem.

A less-desirable alternative would be to disable the cache entirely.

For super-duper bonus points it would be good to enable caching all the time (even across relaunches), since CEF caches the compiled bytecode for JS (and thus doesn't have to parse everything). This might speed up load time significantly. Or it might not. I have no idea.

[gruehle]

Migrated from brackets-shell, issue 100

[njx]

Marking sprint 15. Caching of extensions causes to be a serious pain in the development workflow--in a lot of cases it seems like I have to quit and restart Brackets in order to see changes.

[gruehle]

The root cause seems to be this chromium bug:
http://code.google.com/p/chromium/issues/detail?id=44122

It appears that Chrome does not fully clear the memory cache when doing a forced reload. I tried patching a workaround in CEF, but was not successful (I couldn't find a suitable public API).

There are two workarounds for now:

1. Open dev tools and select "Disable Cache" from the settings panel (note: you must keep the dev tools window open for this setting to stick).
2. Relaunch Brackets. This will always clear the cache.

[DennisKehrig]

I just tested disabling the cache by default on Windows. Search for AppGetBrowserSettings(settings); in cefclient_win.cpp and add the following:

  settings.application_cache_disabled = true;
  settings.page_cache_disabled = true;

Honestly, I'm not sure whether the application cache needs to be disabled as well. Anyway, that worked like a charm.

I think until we actually implement persistent caching (i.e. across relaunches) or do many redundant requests while relying on the cache to sort things out, the cache only causes problems during development and doesn't provide any benefit. So for the time being, we should disable it entirely.

What do you think?

[gruehle]

This doesn't seem to work on the mac :-(

I tried setting both cache_disabled values to true, but extensions still aren't reloaded when reloading Brackets.

[DennisKehrig]

Oh man, this is embarrassing. Apparently the "disable cache" setting I had set with the remote debugger for a different Brackets session (different EXE) got applied to the newly compiled one and that's the only reason it worked. Everything seemed to fit...

I just saw this: http://magpcss.org/ceforum/viewtopic.php?f=10&t=910
Quote: "None of these settings keep files from being cached in memory. You will likely need to use one of the standard techniques for avoiding the browser cache."

I am speechless, I have no idea what effect the settings are supposed to have, then.

[DennisKehrig]

Also tried enabling the toolbar and using browser->ReloadIgnoreCache() instead of browser->Reload(). Which, keeping with above tradition, didn't ignore the cache, obviously.
Also tried calling request->SetFlags(request->GetFlags() | UR_FLAG_SKIP_CACHE) in ClientHandler::GetResourceHandler of client_handler.cpp. No effect because the request is already performed at this stage. Seems to me like we'd need to compile CEF ourselves to change this when the request is created.

I really couldn't let this sit on me, so I created a client-side solution to disable the cache.

[peterflynn]

@gruehle should this be closed (or FBNC) now? Dennis's pull request doesn't provide this exactly, but this bug was also tracking #1551 since it was closed as a dupe...

[gruehle]

Yes, it should be closed. Reloading Brackets will now fully reload everything. Thanks Dennis!

[DennisKehrig]

Awesome, happy to have helped!

[TomMalbran]

Since this is closed, should it be removed from the Known Issues in the current sprint release notes? Or does this problem still applies there?

[gruehle]

@TomMalbran - I removed this item from the known issues list. Thanks for pointing that out!

[peterflynn]

Note: there is still an issue when a new user opens Developer Tools. Dev tools defaults to caching enabled, and the fix here can't work around that because we can't snatch the remote debugging connection back when Reload is invoked. I've updated the How to write extensions docs to clarify that a one-time step to disable caching is still needed -- if you start using developer tools.

[DennisKehrig]

You can use patch_devtools to make the dev tools always disable the cache. This just didn't make it into the Brackets-Shell script chain because it seemed too fragile.

[davutg]

I'm new to brackets. I've recently downloaded it from the brackets.io site. This issue seems still exist on current release for my environment. Even though I've disabled cache I can't switch to any dark theme extension . BTW, when I open brackets I see a logging error in the console. When I refresh for theme extension the page crashes and developer console complaining for it. I can only close the app from task manager. Any workaround else ?

[davutg]

When I debug it I see that

file:///C:/Users/demo/AppData/Roaming/Brackets/extensions/user/os-x-style-dark-theme/main.js

And there isn't main.js exist on that place. It is same for some other extensions. Is something changed on extension programming policy ?

[davutg]

I didn't notice View->Themes menu at first glance. It was that !!!