WTH: Why doesn't command-F (or control-F) work to search (on Chrome, Edge, ?Firefox)?

Your question is wrong in my opinion since we are talking about two completely different things.
Googles pages are more or less just HTML. It’s very basic and everything is downloaded to your computer when the page loads.

But lets take a more comparable page. Youtube.
You can’t view the video that is not buffered.
That is more comparable.

However I understand your question and frustration.
I don’t like those kind of pages either, but they save lots of bandwidth.
Most likely what you are looking for is at the top and not 10 pages down, so the data transmission can be 1/10 th.

I would rather have a “download raw data” button that gives you all in the format you want.
That way you keep the low bandwidth for every day usage, but can get it all if you want.

Or “paginate after x entries…”, then people with bandwidth concerns can save their 2MB of text (total guess but when it’s compressed I bet that’s about right) and I can do my searches til the cows come home.

Edit #2. But I will say this. I understand paginated and lazy loading of pages. This doesn’t seem like lazy loading… because I can load the page (NOT SCROLL DOWN), turn off wifi, and scroll all the way down without any problem or missing text.

Edit #3. Or go to Developer tools on your browser/Network and hit refresh. Watch the waterfall. It doesn’t change after you start scrolling. I don’t think this is about conserving network resources, but perhaps loading dynamically things into RAM (this I know not how to test).

And if you have 3 months of logging? Everyone thinks that history is slow with a day’s worth of data. Your PI would die trying to serve up all that. It would be better to just apply a filter instead of leveraging find.

For starters, I use a real server, not a pi.

But as I made perfectly clear in my most recent post (see the edits), everything is already served up! The server saves nothing by doing what it’s doing.

@petro, load your log, turn off Wi-Fi, and scroll down. What happens? What does this tell you about what is happening with the server? Serious question. I’m not a programmer. Thanks

I don’t follow your question… What does wifi have to do with it?

Ok, you are implying that somehow the stress on the server is related to my ability or inability to search beyond the first 100 entries (I say 100 but in reality it seems to be however big your window is while displaying the entries, in actuality mine is about 25 entries). I don’t understand how that’s the case. My server sends the entirety of the log to my browser, it does not break it into chunks as I scroll down. So where does the comment “Your PI would die trying to serve up all that” come into play in this conversation?

I don’t know about you but mine only sends whats between the specified dates. It’s an SQL lookup, more data causes more time. It’s not going to search outside the date range and the current filters only work off entity_id. A solution that many would get behind is a filter that works off friendly names applied prior to the lookup to speed things up.

Please re-read the thread. We’re arguing different points.

I want to be able to hit command-f in my browser and type in a string and if it matches the last entry on the page, it should show up in my in-browser search function. I’m not implying that the logbook load 30 days worth of data. I’m fine with 1 day, but I feel like I should be able to use my browser to search to the bottom of that page. Does that make sense?

Oh I understand but that’s not how webpages work and we don’t have control over what chrome(insert other browser) finds. I guess that’s worth mentioning.

That’s how it works on [insert most other websites here] with the same browser. :slight_smile:

Same thing happens with the logbook on Firefox, btw.

but as others have said… that’s simple html. Your asking to find things that aren’t loaded… It’s fruitless for me to argue this at this point. Good luck with your WTH

1 Like

Why do you say it’s not loaded though? That’s what I don’t understand. What part of it is not loaded? If it’s not loaded then turning off Wifi and scrolling would give me a blank window, but that’s not the case.

I’m not trying to be difficult, that’s just the way I am, apparently.

It’s not loaded into the browser. The find function built into browsers searches whats loaded onto the page. When you scroll, things that are out of view are destroyed (typically by the browser), then when you scroll back, they are created again.

Just take a look at it yourself. In chrome, hit F12. Select the whole element and scroll down to the bottom on the shown html. You’ll see that the last loaded item is only a few elements below the bottom of your screen.

The 2 red boxes are the last visible items.

Orange box is the last item that is loaded into the ‘view’.

A good comparison would be this discussion forum thread. You can’t use the native cntrl-f find to search the entire thread, because only a small part of it are loaded into the view. The need to search is common, so ctrl-f is hijacked to be replaced with a (I’m guessing) js-powered search that searches the entire thread contents, instead of just the browser loaded view.

I think the non-obvious thing for most folks is that the Logbook is a dynamically loaded/changed view. It’s a simple enough page that loads very quick (unlike scrolling fast on Twitter, this forum, etc) and so makes it non-obvious that it’s loading each page on the fly.

I can appreciate the desire for the cntrl-f find, but if I could have only one (due to development time/effort), I’d go with the more general purpose filters linked earlier, since it’s more powerful.

3 Likes

That makes sense; the part about it dynamically loading into active memory instead of the (incorrect) argument that it was saving processing on the server, especially so.

I don’t understand the filter part, but many times per day I try to search for certain elements (without reaching for my mouse) Abe am disappointed that it only searches what’s visible (“loaded”).

This forum & Twitter, however are different in that what is not loaded, is actually downloaded on the fly whereas the logbook page is downloaded in its entirety but (due to JavaScript?) it has been decided to only load certain parts of it.

It’s not incorrect if you load everything in your history to find them, which was the point I was making.

Wasn’t meant to be a jab.

Then why even say it?

Because multiple people were giving incorrect advice throughout many replies, and I was trying to summarize what’s been said, as this topic is spiraling (as evidenced that I’m even typing this message) and it seems pretty clear that whatever point was trying to be made is now being overtaken by answers to a question that wasn’t asked. I appreciate your help, & this isn’t personal.