Chronologically ordered Firefox history via dedicated trigger fh

[ffpyt]

Add ordered Firefox history via dedicated FirefoxHistoryHandler

Motivation

The existing FirefoxQueryHandler uses IndexQueryHandler which ranks results by fuzzy match quality. This is great for searching bookmarks & history by name, but makes it impossible to browse history in chronological order — Albert always reorders results by relevance, even for an empty query.

Changes

New FirefoxHistoryHandler(GeneratorQueryHandler)
A self-contained handler triggered by fh that yields history in recency order on every query. Typing after the trigger filters results by title or URL via a SQL LIKE clause while preserving the ordering. Because it uses GeneratorQueryHandler, Albert displays results exactly as returned without reranking.

Refactored Plugin
The plugin now properly separates concerns: Plugin(PluginInstance) owns shared state and configuration, while query handlers are standalone objects passed shared state at construction time. extensions() returns both handlers, letting Albert dispatch each trigger independently.

New get_recent_history() function
A dedicated SQL query separate from the existing get_history() (which is preserved unchanged for bookmark/history indexing). It filters out entries where last_visit_date IS NULL — avoiding unvisited prefetched or autocomplete URLs polluting the results — and returns rows ordered by last_visit_date DESC with an optional search filter and limit.

Triggers

Trigger	Handler	Behaviour
f	FirefoxQueryHandler	Fuzzy search over bookmarks and history
fh	FirefoxHistoryHandler	History ordered by most recently visited

[Copilot]

Pull request overview

This PR adds a dedicated history-browsing pathway for the Firefox plugin so users can browse history in true recency order (without Albert’s fuzzy-ranking reordering), while keeping the existing f fuzzy search behavior for bookmarks/history indexing.

Changes:

• Added FirefoxHistoryHandler (GeneratorQueryHandler) triggered by fh to return history in last_visit_date DESC order with optional LIKE filtering.
• Refactored plugin structure so Plugin owns shared config/state and exposes two independent handlers via extensions().
• Added get_recent_history() SQL helper to retrieve non-null last_visit_date entries ordered by recency.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
__init__.py	Adds get_recent_history, introduces new FirefoxHistoryHandler, and refactors plugin into separate handlers with dedicated triggers.
README.md	Documents the new fh trigger for chronological history browsing.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[tomsquest]

Still not tested @ffpyt . Sorry for the delay. Cannot commit time for now.

[tomsquest]

@ManuelSchneid3r Tested here. Works fine!

TL;DR: new handler to display recent history --> fh display my last closed tabs

[tomsquest]

Ah just found that the scan for bookmarks/history ran twice

16:57:50 [info:albert.python.albert-plugin-python-firefox] Found 1472 bookmarks
16:57:50 [info:albert.python.albert-plugin-python-firefox] Found 95711 history items
16:57:52 [info:albert.python.albert-plugin-python-firefox] Found 1472 bookmarks         # <--- second
16:57:53 [info:albert.python.albert-plugin-python-firefox] Found 95711 history items

@ManuelSchneid3r I think I need your opinion here: 2 handlers, so theoretically, 2 instances => 2 scans. Unless we can share something between the two?

@ffpyt Maybe you have an idea? (I did not dig much here)

[ffpyt]

@tomsquest Thanks for your testing!

You are right that my changes caused the duplicate scan of bookmarks at startup.
It should be fixed with 28e9e21.

Basically, the root cause was calling updateIndexItems after instantiation of the FirefoxQueryHandler.
This is not desired as last sentence of updateIndexItems documentation mentions:

    @abstractmethod
    def updateIndexItems(self):
        """
        Updates the index.

        Called when the index needs to be updated, i.e. for initialization, on user changes to the
        index config (fuzzy, etc…) and probably by the client itself if the items changed. This
        function should call ``setIndexItems`` to update the index.

        Do not call this method on plugin initialization. It will be called once loaded.
        """

With this change my debug log does not show a duplicate scan anymore.

Technically, there is still a "duplicate scan" not visible in the log just now:
FirefoxQueryHandler (previous functionality) and FirefoxHistoryHandler (new functionality) both query independent from each other.
FirefoxQueryHandler gets the bookmarks and optionally queries also history (in case it is setup in preferences).
FirefoxHistoryHandler also queries the same history (in contrast it also sorts it).
FirefoxHistoryHandler just does not have a log message upon completion of the query.

Do you think this shall also be optimized / fixed?

[tomsquest]

@ffpyt Seems fine on my side. I don't have any duplication whatsoever (1 log line for bookmarks, 1 for history, that's it).

So seems good for me! 👏

[ManuelSchneid3r]

I think 50 is still a number a user would want to browse through sometimes. If you want to save resources, use the generator to materialize the items lazily (see comment below) and fetch some more items from the database. I cant tell which is a good number. If it comes without penalty/runtime cost i'd go for several hundreds.

[ffpyt]

Thanks for the suggestion!

I went for 1000 and could not see any performance penalty.

Lazy population 32fc474 and increasing limit 197f9de

[ManuelSchneid3r]

claudes suggestion:

You can use itertools.islice to lazily chunk the generator:

from itertools import islice

history = get_recent_history(places_db, search=context.query.strip())

def make_item(guid, title, url):
    return StandardItem(
        id=guid,
        text=title if title else url,
        subtext=url,
        icon_factory=lambda: Icon.composed(self.icon_factory(), Icon.grapheme("🕘"), 1.0),
        actions=[
            Action("open", "Open in Firefox", lambda u=url: openUrl(u)),
            Action("copy", "Copy URL", lambda u=url: setClipboardText(u)),
        ],
    )

it = (make_item(guid, title, url) for guid, title, url in history)
while chunk := list(islice(it, 10)):
    yield chunk

The key idea: islice(it, 10) consumes at most 10 items from the iterator each time without materializing the whole thing, and the walrus operator (:=) stops the loop once islice returns an empty list.

[ffpyt]

Wow, fancy. A double first time encounter for me:

• Generator expressions ( what my mind identified as simply a tuple comprehension)
• A reasonable use case of the walrus operator

Still for me this is quite an exceptional concept I added this as comments to prevent confusion of potentially my future self or another human being.

Done in 32fc474.