Invalidate image cache when modified on disk

[fxha]

Description

An image is not correctly reloaded when the image is modified on disk.

• Can you reproduce the issue?

Steps to reproduce

1. Create image: ![](a.png)
2. Change a.png on disk

Expected behavior:

The modified image is displayed.

Actual behavior:

The image is not reloaded because it's fetched from cache.

Versions

• Mark Text: all
• Operating system: all

[Jocs]

Change a.png on disk

Do you mean change the name of a.png or just replace it to another image with the same name?

[fxha]

Do you mean change the name of a.png or just replace it to another image with the same name?

Just modify the existing image. E.g. change the color from red to black.

[Jocs]

Is this issue the same with #656 ?

[fxha]

I don't think so because we add all images to an "image cache", so we don't have to make continuous http requests but local files may be modified. I think the issue is that we add local files (file://%path%) to the cache as well.

[Jocs]

After listening to (after we'll do) the local image modification, you also need to inform the editor to reload the markdown file. At this same time, we also need to clear the image cache to ensure the image is loaded?

[fabiospampinato]

@fxha Isn't Electron just caching file:// urls on its own? 🤔

[fxha]

Isn't Electron just caching file:// urls on its own?

@fabiospampinato I don't think so because it's only locally, so it wouldn't make any sense, but Chromium may prevent to reload the image because the URL is the same as before on the same HTML element and we may need to add a semi-random suffix like ?r=0. However, the main issue is that we don't listen for image changes on disk.

[fabiospampinato]

but Chromium may prevent to reload the image because the URL is the same as before on the same HTML element and we may need to add a semi-random suffix like ?r=0

That's what I meant, i.e. the following:

I think the issue is that we add local files (file://%path%) to the cache as well.

I don't think is correct, you don't need to do anything to get this behavior.

[fxha]

I think the issue is that we add local files (file://%path%) to the cache as well.

I don't think is correct, you don't need to do anything to get this behavior.

If I remember correctly, we're using a map/cache that maps paths/URL's to images for better render performance, so we can reuse the old DOM element instead making another HTTP request. But I'm not totally sure and currently don't have any time to invest the issue.

@fabiospampinato Do you have a similar issue in Notable? That would mean Chromium does caching.

[fabiospampinato]

If I remember correctly, we're using a map/cache that maps paths/URL's to images for better render performance, so we can reuse the old DOM element instead making another HTTP request.

That's interesting, does that help performance a lot? 🤔

@fabiospampinato Do you have a similar issue in Notable? That would mean Chromium does caching.

Yes, and I'm not doing any kind of manual caching.

[kiyoka]

I think it is possible to use a periodic timer to check the update time of image files.

[rugk]

Same issue in #2320

[kiyoka]

I have experimented with this issue and found it to be quite difficult.
It seems that Chromium caches the same URL even if I disable the caching of the loadImageMap variable.