Hi Rick,

I've noticed that the image caching in DM appears to be quite persistent, and that even refreshing the preview (picking from the menu or hotkey or right-click menu in the preview pane) doesn't always detect an updated image file on disk. Or I'm doing something wrong. 😃 FWIW I do tend to just type in my image refs as opposed to dragging & dropping or using the GUI to pick. I'm on the current version (4.1.1) but I feel like this is not a new thing.

As an example from a doc I'm working no now, I added a particular image, and then modified it on disk. Here's what I see in the file system:

and here's what I see in the DM preview:

I eventually figured out one hoop to jump through that consistently refreshes which is switching to a different MD doc tab, and then switching back to the one I'm currently editing. But I'm just curious if there's something that might be preventing the "standard" refresh options from behaving consistently. Besides the end user, of course. 😉

I just tried this here:

• Add an image to a topic
• Display - works fine
• Make a change to image
• Save
• Make a change in doc - image doesn't update (expected behavior!)
• Refresh the Preview (Context - Refresh Browser)
• Changed Image is refreshed

Seems to me it does what you would expect?

Typical text updates from the editor don't reload the entire topic document, but just replace the the main Html content - ie. a partial Html DOM update. Since the image ref hasn't changed the image doesn't reload.

Refresh forces a full page reload and in my experience that will also refresh any embedded images. For 'hard' refreshes I've now added some logic to clear the browser cache altogether so it acts like a hard refresh now.

Also many browser hot keys work in both the editor and previewer. So ctrl-shift-R to hard refresh should also work.

That said I know that in my desktop browser Brave (which is using the same Chromium engine that most browsers and WebView use) I often see issues with image not refreshing no matter what I do. The only way I can get that to work sometimes is to go into Dev Tools and the network tab and Disable Caching.

However, in MM and DM the Refresh feature seems to work as expected when a change is made to the image...

+++ Rick ---

Agreed, that's what I would also expect. But I can't say I always experience that, and that's what I was trying to illustrate with the screenshots. I can say that switching document tabs works 100% of the time so that's my workaround when it decides to misbehave. 😃

I've added some additional logic that clears the cache on the Refresh Browser command operation.

public void Refresh(bool noCache)
{
    if (WebBrowser == null || string.IsNullOrEmpty(WebBrowser.Source?.ToString())) return;

    if (noCache)
    {
        WebBrowser.Dispatcher.InvokeAsync(async () =>
        {
            // THIS CODE HERE!
            await WebBrowser.CoreWebView2.CallDevToolsProtocolMethodAsync("Network.clearBrowserCache", "{}");
            WebBrowser.CoreWebView2.Reload();
        }).Task.FireAndForget();
        return;
    }

    WebBrowser.CoreWebView2.Reload();   // not working reliably if file initial navigate failed
}

Previously the 'hard' Refresh was simulated by clearing out the URL and the resetting it which is supposed to trigger a page reload. A page reload on it's may not be enough though to also refresh the depdendent resources like images - the updated code by clearing the cache should handle that.

ps

To be honest I see no difference since the old code was already working for me. But I wonder if the old code in some cases had a race condition that would intermittently not work because the change of URL was not actually detected by the UI or the Dispatcher delay between the Url changes was just to fast. IAC, the new code should take care of that reliably.

+++ Rick ---

Cheers to that, Rick! I've updated and will now try to unlearn my new habit.

I had a chance to test this out again today, and I continue to be able to not see the updated image file by using the Refresh Preview function. (It's a gift, I know.) Here's my typical workflow.

I have an MD document which is a draft of an update email we periodically send to our clients. I typically have several png files to go along with the text that nobody will read unless there's a pretty picture to go with it. I type the markdown code like this:

A new thing blah blah blah...

![New Thing](20260204-image2.png)

This new thing does blah blah blah...

As I go through the draft process I may get or create updated versions of the images files. External to DM (of course) I replace the existing file with my new file. I did this again today in 4.1.2, and used the Refresh Preview option from the Edit menu. It did not show me the updated image on disk. I used my new habit and switched to a different open MD tab, and then back. Presto chango!

The one other bit of color commentary I will add is this. I made no direct changes to the MD text prior to attempting the refresh, so there was no editor event to let DM know something had changed. I base this observation on the fact the DM doc Save button was unlit the entire time, as I would expect since I didn't change the contents of the MD file itself. So if I slightly understand the architecture, DM has to detect some async event from the file system to understand there is something to update in the preview container, and something in the way I do this is resulting in that not happening.

Latest version is 0.4.3.2…

I am mixing up my Monsters. I should have put this in the MM bucket. My apologies.

The same change was applied in Markdown Monster but that hasn't been updated yet.

Thanks. Can this thread be moved to the proper location? (And the subject fixed... )

Updated Markdown Monster today - and it has the cache clearing change. Be curious to see if that works better.

Again for me it worked before, but with cache clearing hopefully this also works for you.

+++ Rick ---

Thanks. I'll let you know how it goes.

FWIW I just downloaded 4.1.3 and when I went to run I got the security warning. I know how to unblock but don't recall having to do that on a regular basis for either MM or DM updates. Missing cert, maybe? Having said that, I unblocked it and got this when I went to install.

Not sure what version that is or where you're getting it from.

Latest version is 0.4.3.6

I did have a bad installer because the Trusted Signing was failing for one batch and that may have been the one, but that was a couple of weeks ago.

+++ Rick ---

That's from the MM download you said I should fetch and test. 😃

Oop sorry... getting monsters mixed up again 😄

Ok just checked and sure enough the entire download is corrupt. File size way to small - looks like the final upload failed because the local installer that I was testing of the release worked fine.

I've been having Internet Problems in the last couple of days - and I guess it must have stalled out because it was so slow, and I probably just killed the terminal before it was done.

Just republished. Still running into problems with Azure Trusted Signing - it failed to sign the Setup.exe on several occasions. I had to build multiple times to get all of the signing to go through. Not my connection at this point since that's working again, but on Azure's end - dropping the signing session.

IAC, should be all good now.

Thanks for the heads up.

Just grabbed 4.1.4 (allegedly) and I'm not sure you got what you expected? FWIW I still have an MM installer from December that's ~20MB. The 4.1.3 and the one I just grabbed are around 6MB. And when I check the properties it still shows 4.1.3. See the screenshot. The first one is from December, the 2nd from this morning, and the 3rd from just now.

Use a private browser session. You have a caching problem. Most likely your corporate router is caching stuff way to agressively.

Latest version is 4.1.4.

+++ Rick ---

Or leave it alone for the weekend and try it again on Monday. 😃

I got the right installer this time. FWIW I'm just using Chrome. I don't think I have any unusual plugins or extension installed that relate to download.

I will most likely have an opportunity to test my workflow with this version, and will let you know how it behaves.

Had a chance to update my release MD doc today. I got an update for an existing image and a new image to add. Refresh Preview from the edit menu did not. Switching from and back to the doc did. ¯\(?)/¯

Not sure what would cause that to behave so differently to what I see - I can reliably replace the image file and see the change on a refresh.

Note you have to use explicit Refresh Browser from the context menu or Ctrl-F5.

+++ Rick ---

Well, I am an end-user and endlessly creative. 😃

I was using the Refresh Preview (CTRL+Shift+R) option from the Edit menu. I'll try the Refresh Browser option from the preview pane context menu next time I have the chance to test this.

Using the Refresh Browser in the preview pane does the trick. Duly noted, and thanks for the review.

So I spent some time experimenting this morning to add an explicit image refresh after each document refresh that goes through and reloads images asynchronously in the background. This happens now even if the document is updated without a reload from disk by refreshing the image link with a unique querystring value. So if you make a doc change, and an image has changed the image now auto-magically updates.

This might impact performance unfortunately, so I have to play with this some more to see if this will have adverse affects in large documents and memory usage. Essentially this means that images are constantly reloading and getting saved into the cache over and over again which also sucks. But both reload operations now properly refresh the images as do any of the copy/drop operations.