It wouldn't be so bad if the window closed but at least remembered the entry. I often have the issue where I had to search up an entry (credit card info for example) and then when I reopen the extension window I have to start the search all over again.
For those that use LLMs in a similar manner to a search engine the Anthropic team (unlike Meta AI and Google Gemini) have made it easy to use Claude from right within your browser. In Firefox add a bookmark with the following values:
Also in Firefox Dev Edition settings (in the Firefox Labs section) you can turn on their AI chatbot feature which gives you the option to send the selected text to Claude or other chatbots and opens their response in a sidebar.
Also, if you prefer using AI assistants as desktop apps that feel separate to the browser and you can open directly, you can download Progressive Web Apps for Firefox [1] and create a separate shortcut for a sandboxed profile of Firefox with less visual clutter that open the assistant directly.
Yes, I'm aware of @gemini on Chrome. If you look at how it's implemented they are purposely stashing the query into a HTTP header so it's not possible to use a simple bookmark to launch it.
Query parameters are so tired. All my homies embed their queries into the password portion of a basic auth header. Keeps your queries super secure from spies and competing browsers.
This doesn't seem to work for me. I'm getting "%s" as the initial prompt, even though the text is properly displaying in the URL. Almost seems like an issue on the Claude side.
I'm one of the naysayers as an experienced Java developer that supports checked exceptions. I find the move to runtime exceptions very disheartening though I will say that in a world dominated by web applications with a clear request/response cycle it's very easy for the container/application to implement a high-level error-handler so I think this skews people's sense of the value proposition of checked exceptions. I've done a fair bit of work over the years writing daemons of various types and having checked IO exceptions among others has been a lifesaver. I also feel that vilifying use of generic exceptions (IOException, SQLException) in favour of implementation-specific exceptions was a mistake. If instead, we had encouraged a smaller set of mostly platform-defined exceptions I believe people would have found the exception "noise" to be lesser. While there are cases where a custom exception sub-type can be useful, in many cases they are not. I agree with the grandparent comment that we may have been better off without runtime exceptions at all, leaving us with simply checked exceptions and errors.
Checked exceptions were an ideal. From a halcyon Valhalla of fallen unix programmers trying to impart their wisdom to the ignorant masses.
I too would like to live in this world.
However, while I don't have specific exceptions at the tip of my tongue, Even sun failed in many of their jdk apis to produce a good checked exception design.
I don't see any connection between going public and giving the average consumer more input into the direction of the company. Making a company public means the company is beholden to operating in a way that maximizes return to the shareholders. Sure an average consumer can buy shares in the company but the average consumer isn't going to be sitting on the board.
On the pricing aspect do viewers of Jam reports get charged as a seat or just the staff that are creating the Jam reports? Eg. if a Jam report is attached to a JIRA ticket does everyone who might ever need to view that report need to have a Jam license/login to view that information?
It would be great to have a FAQ page on your site mentioning this. I was on your docs page and did a search for "firefox" as well as "safari" in the search box and there were no hits at all. Seems like something that people would often be checking for.
Love this tool, want to buy it for our team. Unfortunately, a tool that doesn't support Safari can't readily be used to help iterate products that use default browser or webkit webviews on MacOS or iOS.
We've noticed many tool devs think everyone uses Chrome (because those devs got non tech people in their social circle to install Chrome so "everyone they know" uses Chrome), but users who don't know devs just use whatever's there, and that means iPad, iPhone, and most Mac "end users" are Safari.
Along with being needed for those users, any tool that looks this good and works this magically is also going to appeal to dev teams that can appreciate why users like iPhones and designers like Macs, those teams will want this to work in Safari too.
That said, if you couldn't readily support Safari, I wonder if your extension could be adapted to work in Kagi's Orion browser that supports Chrome and Firefox extensions (to an extent), while being based on WebKit. Perhaps that's a path that could allow webkit debugging.
We would definitely pay for a Safari extension to be installed from Apple app store for each of our UX devs, product managers, and canary users.
For enterprise deployment, it needs to come from Apple app store or be distributed as an installable package through an automation mechanism. MAS (Mac app store) is easiest.
The extension needs to either be free, or have a "full price" version, so that it can be licensed per seat/user through corporate volume purchasing to run on employee devices. The way managed devices work, there's no way for companies to pay for employees to use in-app purchases (IAP).
I looked at the Sunshine / Moonlight combination at one point as I thought something focused on latency would also be great for interactive desktop applications. It turns out though that clipboard synchronization isn't even supported so that was a complete non-starter for me.
reply