Steps to reproduce: 1. Add console.log("123") to the end of WebInspector.contentLoaded. 2. Build and open the inspector for some page 3. 123 is printed 4. Change console.log("123") to "456" 5. Build, close, and reopen the inspector 6. 123 is printed again. Expected behavior: Step 6 should print 456 to the console, but stale copies of the interface are picked up. This works as expected if you close the inspector, navigate to a different page, and open the inspector. It also works if you open the 2nd level inspector. My guess is that we are holding onto the inspector WKWebView for some time to reduce re-open latency, but not reloading the resources in that case. Or, there is some sort of cache configuration bug?
<rdar://problem/20677296>
The out of process stuff added a webViewCloseTimeout to WebInspectorProxyMac. It is 60 seconds. Within 60 seconds we will reuse the WKWebView to avoid slow process creation.
Right. I am wondering if we need to explicitly reload the inspector if we reuse the existing webview in platformCreateInspectorPage(). I need to debug this further.
We issue a new navigation every time the inspector is opened, whether it was reused or a new view. m_inspectorPage->loadRequest(URL(URL(), m_underTest ? inspectorTestPageURL() : inspectorPageURL())); I don't believe it should be using cached versions of the files. I need to turn on the network logging spew and reproduce to see what it thinks it is doing.
I guess setting ResourceCachePolicy on request (accessed using a loader client) is the easiest way to go for now. Using a meta tag can get Main.html to be revalidated/evicted from cache, but none of the subresources are (and they have no HTTP headers because they are local files).
Apparently it reloads with revalidation if using window.location.reload(), but window.history.go(0) and internal WebCore commands don't. Not sure what's up with that, but I guess I'll close this bug. Here's the log spew: CachedResourceLoader::determineRevalidationPolicy reloading due to missing cache validators. Evicting resource 0x11e85db00 for 'file:///Users/bburg/repos/webkit-tot/OpenSource/WebKitBuild/Debug/WebInspectorUI.framework/Resources/Views/BezierEditor.css' from cache Loading CachedResource for 'file:///Users/bburg/repos/webkit-tot/OpenSource/WebKitBuild/Debug/WebInspectorUI.framework/Resources/Views/BezierEditor.css'. MemoryCache::add Added 'file:///Users/bburg/repos/webkit-tot/OpenSource/WebKitBuild/Debug/WebInspectorUI.framework/Resources/Views/BezierEditor.css', resource 0x1309ae900 ResourceLoadScheduler::load resource 0x1309aeec0 'file:///Users/bburg/repos/webkit-tot/OpenSource/WebKitBuild/Debug/WebInspectorUI.framework/Resources/Views/BezierEditor.css'
(In reply to comment #6) > Apparently it reloads with revalidation if using window.location.reload(), > but window.history.go(0) and internal WebCore commands don't. Not sure > what's up with that, but I guess I'll close this bug. Here's the log spew: > > CachedResourceLoader::determineRevalidationPolicy reloading due to missing > cache validators. > Evicting resource 0x11e85db00 for > 'file:///Users/bburg/repos/webkit-tot/OpenSource/WebKitBuild/Debug/ > WebInspectorUI.framework/Resources/Views/BezierEditor.css' from cache > Loading CachedResource for > 'file:///Users/bburg/repos/webkit-tot/OpenSource/WebKitBuild/Debug/ > WebInspectorUI.framework/Resources/Views/BezierEditor.css'. > MemoryCache::add Added > 'file:///Users/bburg/repos/webkit-tot/OpenSource/WebKitBuild/Debug/ > WebInspectorUI.framework/Resources/Views/BezierEditor.css', resource > 0x1309ae900 > ResourceLoadScheduler::load resource 0x1309aeec0 > 'file:///Users/bburg/repos/webkit-tot/OpenSource/WebKitBuild/Debug/ > WebInspectorUI.framework/Resources/Views/BezierEditor.css' So, we can issue that reload command if reopening the warmed-up inspector WKWebView. I guess that is a separate bug from adding a Reload menu item, worth fixing (but less urgent).