Bug: editor-menu event's cursor position is wrong if menu action taken when window isn't focused
pjeby opened this issue · 3 comments
Steps to reproduce:
- In a list of external links, position the cursor on one link
- Switch to another app or window
- Switch back by right clicking another external link in the editor
- Cursor position of the editor should be the position of the new click, but it's at the old one instead
Likely related: https://forum.obsidian.md/t/context-menu-on-link-does-not-correctly-position-cursor-in-live-preview-on-task-switch/65315
It appears that the code which triggers editor-menu knows the correct cursor position, but does not apply it or pass it on to the editor-menu handler. Perhaps the position could be added as an extra argument to the event? (Assuming the underlying issue of the improperly positioned cursor can't be fixed directly, that is.)
While trying to figure out a workaround for this, I discovered the undocumented url-menu
event, which works to address the specific issues I was having (detecting the wrong external link). Perhaps that should be documented as well?
Weird, I can't seem to reproduce this.
test.mp4
Hm, I can't repro on 1.4.14 now either, even though it did exist on 1.4.3 - and I'm using the exact same sandbox file I did to get a minimal repro before I filed the original issue. I wonder what changed? (I assume it wasn't intentionally fixed since there's nothing noted on the bug report.)
Well, either way, the API issue is that there's no documented way to access the menu for an external link - neither clickableTokenAt nor the url-menu
event are published in the API. Using url-menu works around the apparently now-fixed cursor positioning issue, but being able to get the extent of the link would be nice too.
We'll expose url-menu
in the next update!