Bug: "Tag name to denote inline geolocations" breaks map view on iOS when vault has images in it

[Jackson Kruger]

I've found a scenario where the map view will not populate with any locations inside the iOS mobile app, but works fine on desktop versions of Obsidian (don't have an android device to test on).

Steps to reproduce:

1. New vault
2. Add this plugin
3. Add a note with an inline geolocation (note that the map view still works fine at this point)
4. Set the value of the option "Tag name to denote inline geolocations" to something, I've been using "#locations" (map view still works fine)
5. Insert an image attachment into this file or any other file, such that the image is added to the vault
6. Open the map view, and observe that it is now empty

This was tested with:

• Version 3.1.1 of this plugin
• iOS Obsidian Mobile app v1.4.6
• iOS version 15.6

Removing the value from the "Tag name to denote inline geolocations" option resolves the issue, but is not a suitable workaround for vaults where that tag is relied on instead of the frontmatter YAML. Removing all images from the vault also fixes the issue.

This problem does not occur in the dekstop versions of Obsidian.

I'll be investigating this a little further to see what else I can find.

[Jackson Kruger]

Alright, I enabled debug logging and installed the "Logstravanganza" plugin to get the logs on mobile.

Here's the error message that's spat out when opening the map view:
"The file “D76383B3-6221-4C53-A644-6A3A7CD4A048.jpeg” couldn’t be opened using text encoding Unicode (UTF-8)."

This occurs downstream of the buildMarkers function in markers.ts. Looks like this is called by updateMarkersToState inside mapContainer.ts with the result of calling getFiles() on the vault, without filtering. So somewhere in here (probably when asking Obsidian for the tags of that file) it tries to open it as UTF-8 encoded, which fails for the images. Still not clear why this is a problem on iOS and not on Desktop - perhaps that indicates that this is actually an issue with Obsidian's API.

[Jackson Kruger]

Perhaps line 535 of mapContainer.ts should be calling getMarkdownFiles() instead of getFiles()

This would have the consequence that any existing vaults that were using this plugin and had locations contained inside non-markdown UTF-8 encoded files (somehow, not sure if possible), those locations inside non-markdown files would no longer be picked up. Don't know if that's a real/valid scenario though.

[esm7]

Fixed in 4.0.0 -- now using getMarkdownFiles as you suggested, hoping not many users counted on Map View parsing arbitrary files.

[Jackson Kruger]

Great, thanks a bunch! Tested 4.0.0 with the vault that I first found this in and the map view now works.