[BUG] In-line Geolinks Absent from Map (Parsing Failure on iOS; Reproducible)

[hdlnii]

Hi, as usual, big fan,

Yesterday through today, I found something so frustrating, and I think it's quite crucial. Becuase personally, mobile is where I am on the go and is when I need my map the most.

Summary

Essence and Impact

I noticed that on iOS, inline geolinks under certain conditions silently fail to be detected by the plugin's parsing regex. When this happens, there're no error or console warning, the markers are just absent from the map.
The iOS map becomes an incomplete aggregative presentation of all locations data in the vault, with the user unaware.
(still, just a silent failure, and the note's data is unaffected )

Scope and Mechanism Observed

Though this issue does't seem to exist on desktop:
The trigger seems to be a surrogate-pair character (most emoji) appearing somewhere before the geolinks in the note. Root cause appears to be inside JavaScriptCore's regex engine on iOS (so this does not reproduce at all on desktop Electron), specifically, when the plugin's inline-location regex scans text containing a surrogate pair before the target match.

Provenance

I first ran into this because I noticed a note with 7 geolinks only showed 4 markers on my iPhone, while the same note was fine on my Mac (shows all there). So there I started trying to figure out why: the eventual cause was a invisible/hidden U+FE0F character attached to an emoji used in the frontmatter of the note. Deleting it fixed the note on the iPhone map.

But that felt too specific to be coincidental, because tbh at that point my trust to the iOS map was already compromised .. so I kept digging, and it turns out the underlying trigger seems to be broader than that just a U+FE0F. Further testing showed U+FE0F isn't actually required: the emoji alone, with no U+FE0F anywhere nearby (see below, "More Clues"), is enough to trigger the same failure.

My Environment

• Map View 6.1.4
• Obsidian 1.12.7 (both)
• macOS 15.7.7
• iOS 18.7.8

To Reproduce

After some testing, this is what's minimally needed to reliably reproduce it in my environment:
(Please anyone who doesn't succeed, lmk. I'm curious)

Create

a new note whose entire body is just these 4 lines:

---
locations: 
---
🏷 [X](geo:1.0,1.0)

Notice

This 🏷 is already stripped of an invisible U+FE0F character that gets auto attached to it under some input methods (and this still happens!)

Then verify

1. On iOS, this marker does not appear on the map. plugin.layerCache for this file has 0 entries.
2. On desktop, the marker appears normally.

More Clues

On Variations

It appears that other surrogate-pair emoji also work. In my actual notes, the ones I have a lot are 🏷 and 📍.

But here's what's interesting:
The 🏷️ was 2 separate issues stacked together: a surrogate-pair, plus an extra U+FE0F on top.
The 📍 is only a surrogate-pair, no U+FE0F involved at all.
And, any coordinate value works, any link text works.

The specific characters don't appear to matter at all.
What matters is that a surrogate-pair character appears before the geolink, then MapView's iOS parsing skips it, subsequently omitting it from the map

Beyond the Reproducible

I have one particular note that is so frustratingly mysterious.

After I have fixed every single one of my other notes with the aforementioned issue (regarding surrogate-pair and U+FE0F) and had them all correctly parsed and presented on the map on iOS ——— this particular note simply doesn't give out, its inline geolinks just couldn't get parsed correctly with a stable pattern.

And, this still seems to be the same surrogate-pair trigger, it's just that having the surrogate-pair present isn't enough by itself to guarantee failure. The underlying mechanism seems to be also sensitive to the specific geolink's preceding characters' sequence, or almost their "composition" — I tried many times, and could not reduce it to a simple pattern, length or position.

It seems to be something going wrong within WebKit's internals.

Though this seems to happen rarely: in my vault, it happened only once in 600+ notes with the same frontmatter structure, so same note, same result, every time. I just can't predict which notes from the outside. BUT, "happens rarely" is exactly what's worrying — it can happen sooo unnoticeably, and when it does — even just once — it psychologically breaks the trust and reliability of the whole system.

But to be honest, after many shallow but intensive testing on my part, I was only dealing with a blackbox. The actual digging into JavaScriptCore's regex engine was not done.