5

Steps to reproduce:

  1. Browse around in Orion for a while (to at least populate history — for bonus points, import a set of bookmarks)
  2. Enter a query in the Help > Search menu provided by the system
  3. Wait… and wait (1:00 in the recording), while Orion beachballs and then eventually gives some results (that you may immediately miss because you'd clicked during the beach-balling to see if they UI would respond.)
  4. Click the menu again to see the results and or enter more text for a better match
  5. Wait again

NOTE: if one clears the search and enters a new query without closing the Help menu the next search is faster (lagging around the same time as Safari), implying the search results are cached/in memory still, but as soon as you close the menu and try again, you're back to (1).

Expected behavior:
Ideally this menu search would be at least as responsive as Safari.

If this feature is sufficiently responsive it is, in theory, a means to finding a specific page you may not immediately see in your Window menu for instance, but given a Windows' child tabs are not present in that list, this is an incomplete means of finding an open, but hard to find, tab.

See: https://orionfeedback.org/d/998-tab-groups-show-children-tabs-in-window-menu

Putting aside the suggestion above, perhaps a quick way to mitigate this lag would be to exclude Bookmarks and History from the search, if possible? That would at least enable the Help feature to do its basic job, i.e. help users finding menu items.

Orion, OS version; hardware type:

  • 0.99.109.1.3-beta (WebKit 613.1.12)
  • macOS 12.1 (21C52)
  • MacBookPro16,1 (6-Core Intel Core i7)

Image/Video:
NOTE Quicktime screen recordings don't capture the beachball — in this video a soon as any text is entered into the Search field the beachball comes up, and I can't interact with the UI — most time in this recording is spent waiting for the UI to become responsive again.

  • Vlad replied to this.

    transeunt I was not able to reproduce this (search is instant). Can you give more precise steps to reproduce?

        Perhaps it's contingent on having a lot of bookmarks…? I've imported my old Safari bookmarks (over many years!) so there are probably many, many hundreds.

        This seems somewhat corroborated by going to the Bookmarks menu and trying to browse — selecting a decently large folder of bookmarks there was a noticeable pause while (presumably) all the bookmark titles were parsed and populated into the Menu.

        More recordings? Data on my ridiculous number of bookmarks…? 🤔 😄

        • Vlad replied to this.

          transeunt Would you be able to try on a clean install without bookmarks to confirm that is causing the problem? (or delete existing bookmarks)

              7 days later

              Vlad as shown in attached video, once all bookmarks were deleted Help menu search is very fast.

              Ideally perhaps bookmark titles could be cached (or some other tech fix, that I shouldn't presume!) OR perhaps as a 'quick fix', might it be possible to exclude Bookmarks from this search, which is intended to allow quick search of menu items in the first instance.

                  …and just a related note that I might note as a separate ticket — it does seem that Orion's reading/parsing of this set of bookmarks takes longer (is less performant) than the same set when interacting with them in Safari.

                  e.g. searching the Help menu with this same set of bookmarks doesn't result in the same time lag. Likewise when I was selecting them all to be deleted (via Edit Bookmarks) there was notable lag while Orion "caught up" with my selection, scrolling and deletion of the bookmarks, which I did by expanding and selecting all available bookmarks in each bookmark section (Favourites, Bookmarks Bar and Bookmarks).

                    No one is typing