obsidianmd/obsidian-api

Bug: editor-menu event's cursor position is wrong if menu action taken when window isn't focused

pjeby opened this issue · 3 comments

pjeby commented

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?

lishid commented

Weird, I can't seem to reproduce this.

test.mp4
pjeby commented

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.

lishid commented

We'll expose url-menu in the next update!