I have several very long pages in my vault. Not realizing at first that these pages were being lazy-loaded, I was puzzled when I got zero results on a search for text I knew for a fact to be present on that page. The same search succeeds once I’ve scrolled down far enough for the relevant piece of text to be rendered.
I’m thinking the search needs to be directed not to the cache of text already rendered, but rather to whatever cache contains the full text of that page. Any successful search ought then to force the page to get rendered at least to that point.
Alternatively, a link could be added to the bottom of lazy-loaded pages allowing the user to request that the whole page be rendered. I see a couple of references on this feature request suggesting that such a feature once used to exist (a “scroll to bottom” button). But I can’t see any such button in the most recent MacOS (Intel) version. In any case, this solution isn’t as good as the first, because users unaware of the lazy load feature and who fail to click the scroll to bottom button might incorrectly conclude that the text for which they’re searching simply isn’t present on that page.
In-page search may return matching results for non-rendered content, but selecting a result does not render the page to that location. It just navigates to the top of the page which doesn’t address the issue. The more general Ctrl + K does the same thing. To replicate, you can check this on https://docs.logseq.com/#/page/changelog with the search term “replace”. (The shortcuts are a little wonky for me because the browser uses the same shortcuts, but you can click the page’s search button (magnifying glass) and go from there - you would perform Ctrl + Shift + K search via the “show more” shortcut/button in the Commands subheading of the search UI).
The easiest workaround I’ve found is to do the general Ctrl + K search and Shift + click the result to load the desired content in the sidebar. Doing so force-renders that block because it’s only that block ref which is sent to the sidebar (as opposed to a page/anchor style specification).
Another workaround then could be to retrieve the block ref through some other means and paste it in a short page and view from there. I’m not sure how to do this outside a browser, but you can accomplish this by selecting the desired search result, and the page you navigate to is the base page with the desired block given as a url param (as an example, docs.logseq.me/#/page/searchedpagename?anchor=ls-block-{blockref}). Then edit the url to instead be docs.logseq.me/#/page/{blockref} and you get the same result as if it were loaded in the sidebar.
There is a 3rd workaround if you make use of the id:: property. A block returned in search results with this property will display the property value, which you can copy/paste. When specified in double parentheses as with block references, it loads the content. I think of it as the application-local version of the url hacking done in the 2nd workaround.