First quick capture fails on iOS (share) and PC (x-callback-url)

[jonasdiemer]

What happened?

Capturing something via Quick-Capture does nothing the first time.

It usually works the second and subsequent time. So it might be that quick capture doesn't know where to put stuff if the app was freshly opened. Maybe a good default would be the end of today's journal.

Reproduce the Bug

0. Close logseq
1. Share e.g. a website on iOS to Logseq.
2. Alternatively, share something via bookmarklet via x-callback-url/quickCapture
3. Observe that nothing happens

Expected Behavior

Quickcapture is added to today's journal

Screenshots

No response

Desktop Platform Information

No response

Mobile Platform Information

No response

Additional Context

No response

[cnrpman]

If you mean the desktop version, the current deeplink (callback url and open graph url) only works for opened Logseq. It's a known flaw. Fixing this might require some deep look into the Logseq's Electron app launching args. Investigation effort on this is welcome.

[llcc]

@jonasdiemer Regarding iOS, do you mean you failed to share content if the app is not running in background? I couldn't reproduce this.

[jonasdiemer]

@llcc thanks for trying. Yes, that's how it looked like yesterday, but couldn't reproduce now on iOS (so maybe I confused it yesterday).

However, while trying, I found two more issues:

1. After sharing a website from Safari with logseq, then quitting logseq, logseq disappeared from sharing menu for that browser tab (I could still share other tabs)
2. Selected text does not end up in the {text} section of my quick-capture-template. In ideas/changes there? The template works on Mac via callback url.

[llcc]

Thanks for your confirmation. I tested these two issues, but still couldn’t reproduce them as you mentioned. You can check the screencast and please let me know if I did anything wrong. https://www.loom.com/share/93c0742069614dc3a51df15f79a726f0

[jonasdiemer]

Thanks a lot for checking again.

Issue 1. seems to have been a sporadic one (maybe even bug in Safari/iOS rather than related to logseq) - I also couldn't reproduce it.

Issue 2 I am still seeing. Thanks for recording the screencast. Differences between us: a. You used Chrome, I used Safari b. You seem to have a different quick-capture-template, I am using the default? At least when you select text, logseq doesn't capture the URL.

Thinking on point b, it might be that Chrome is only sharing the selected text to logseq. In Safari, I get the same behavior when I share via the context menu of the selected text, rather than the Share menu, which seems to share both URL and selected text (=what I want).

[llcc]

Thanks.

I think I get your point about issue 2. As I can tell, Apple restricts this behavior to get selected text fired if you use the Share menu, while only text without url can only be shared by the Context menu no matter whether you use Chrome or Safari.

There is another similar issue: https://github.com/logseq/logseq/issues/5227

[jonasdiemer]

I see. Strange thing is that if i share to an automaton via the same share menu, i can access text and URL.

My current automation writes this directly to today's file, which can be flaky. So I was hoping to get the same behavior (but stable) by sharing directly.

Shattering to other apps (eg Things3) also provides full details, ie URL, title and selected text, so I assume that logseq just processes what's shared differently...

[ybalkind]

Hi. I am experiencing this issue and I am able to reproduce.

It is occuring on mobile iOS (using iphone 13 mini).

Reproduction steps:

1. open Logseq app on my phone and place cursor on any block that is NOT a on the latest journal page. For example place the cursor on on a block that is in Yesterday's journal page.
2. minimize app, go to browser, click: Share > logseq
3. Logseq app opens with cursor at the same place as I left it. No quick capture appears.
4. If I then move cursor to brand new block (that is not indented) on todays journal page, and then share from browser, the quick capture appears correctly.

The above is one way to recreate, but it also occurs quite frequently even if I haven't used the app today. In all cases where it occurs it seems the solution is to manually place the cursor somewhere in today's journal page.

Let me know if this is not related to the parent thread and if I should rather log this all as a new issue.

Another issue that seems related (but perhaps is the expected result): On mobile, If I place cursor on an indented block on Today's journal page. Then go to browser and click Share > Logseq, the quick capture is captured in the place where I left my cursor even if that block is in the middle of my notes and even if the block already has text. My expectation is that regardless of where my cursor is, the quick capture will always appear at the bottom of my latest journal page as a brand new block.?

[cnrpman]

@ybalkind The quick capture behavior is not finalized. I agree that quick capture should always append the today's journal. May have a discussion on this?

[ybalkind]

Sure, I'm more than happy to discuss. But, even if you don't make it append to today's journal, there is still a bug whereby it doesn't get created at all under the circumstances set out above.

[cnrpman]

@ybalkind Sure. I hope the behavior can be stabilize via the E2E test on quick capture https://github.com/logseq/logseq/pull/5977

[Bad3r]

@ybalkind are you still encountering this issue in the latest release?

[exoji2e]

I still encounter this (quick capture not being created if logseq cursor is on different page) on logseq 0.8.15, iPhone 13 mini.

[cnrpman]

@exoji2e It should be inserted to the journal by default. There's an option :insert-today for config.edn to change the behavior. https://github.com/logseq/logseq/pull/7427 https://github.com/logseq/logseq/blob/1444d2600f086b76537503cf648d8590c1621bc2/src/main/electron/listener.cljs#L162

:quick-capture-options {
    :insert-today false
}