Restarting the Firefox browser signs me out of Kagi

yellow

Steps to reproduce:

Install the Kagi browser extension for Firefox
A popup will appear after installing that asks you if you will "Allow this extension to run in Private Windows." Check yes.
Go to addons settings (about:addons). Go to Kagi extension and then to Permissions tab. Enable "Access your data for https://kagi.com".
Click kagi extension widget in the toolbar. "No kagi session found." Click "Let's go" and log into Kagi.
Click kagi extension widget again. A green checkmark is visible in the top right. Click the Advanced settings button next to the green checkmark and the login token field will already be filled out.
Close the Firefox window.
Open a new Firefox window and go to kagi.com. It will show the main page, requiring another login.

Expected behavior:
Restarting the browser using the Kagi extension will keep you logged into Kagi.

Debug info:
Firefox 115.0.3 (64-bit)
Firefox configured using the default arkenfox user.js template.

brn

Hey @yellow , thanks for reporting this! I can't replicate it on a "regular" Firefox. Can you check if on a non-arkenfox user profile you still have the same problem?

yellow

brn Okay, I created a new profile for the Firefox browser (about:profiles > "Create a New Profile) without arkenfox and I installed only the Kagi browser extension.

I can confirm I still have the same problem when I try to open Kagi in a private browsing window.

More debug info:
Operating System: Arch
Kernel: Linux 6.4.7-arch1-1
Architecture: x86-64

brn

Thanks @yellow this is looking like it's not extension-related, but related to your Firefox settings (I understand you created a new profile, but maybe cookies/storage is cleared when you close the window)?

Without the extension, if you login to Kagi.com and then close and reopen, are you still logged in?

yellow

brn Yes, without the extension and in a fresh profile, I am still logged into Kagi.com after close and reopen.
My typical Firefox settings uses private browsing window that clears the cookies/storage after closing the browser.
The Kagi extension should be able to work around that as it states that it can be used in a private browsing window.
Thanks for you help so far!

brn

@yellow can you confirm if the session and extension work as expected without that clearing setting enabled? I don't believe that extensions have a different private/non-private storage, thus clearing one will clear it for both.

yellow

brn Yes, I can confirm that the session and extension work as expected without the clearing setting enabled.

brn

Thanks for confirming! I'll try seeing if we can use the storage.local API instead, which should persist in those scenarios.

brn

I can confirm we're already using storage.local, so there's nothing I know of that we can do to support your use-case of keeping the extension's local storage data when the browser session is data cleared. I'm happy to implement something that's still privacy-respecting if anyone else knows of an option! FYI @Vlad this is un-doable otherwise.

yellow

brn I'm not sure what happened, but it looks like it's working now after the new Kagi extension update (Version 0.3.6). Thanks!

loloriz

Hi,

Still not working for me (since v0.3). On desktop I still use v0.2 which works fine, but unfortunately on the phone I can't downgrade the extension in the Mull browser.

But it is very easy to reproduce the bug, just disable the history (about:preferences#privacy, set history to "Never remember history") and restart the browser, the session will be lost even if you set in the extension.

V 0.3+

V 0.2

brn

Thanks for so many juicy details! The only thing I can think of that could've changed this behavior from v0.2 to v0.3 (because nothing changed on the local data storage) was the change from v2 to v3 manifest. If you change the v0.2 to have a v3 manifest, do you also have the same issue?

loloriz

I changed the manifest file to v3 and found a very interesting behavior. When I restart the browser I am not logged in the first time, but then it works automatically. So not perfect, but a bit better than v0.3+. 😃

Full diff of the changes I've made:

--- a/kagi_search_for_firefox-0.2/manifest.json
+++ b/kagi_search_for_firefox-0.2/manifest.json
@@ -1,7 +1,7 @@
 {
-  "manifest_version": 2,
+  "manifest_version": 3,
   "name": "Kagi Search for Firefox",
-  "version": "0.2",
+  "version": "0.2.2",
   "description": "A simple helper extension for setting Kagi as a default search engine, and using your session token easier.",
   "background": {
     "page": "src/background_page.html"
@@ -12,23 +12,24 @@
     "48": "icons/favicon-48.png",
     "180": "icons/icon_180px.png"
   },
-  "browser_action": {
+  "action": {
     "default_icon": "icons/icon_32px.png",
     "default_title": "Kagi Search",
     "default_popup": "src/popup.html"
   },
   "permissions": [
-    "https://kagi.com/",
+    "declarativeNetRequestWithHostAccess",
     "webRequest",
     "webRequestBlocking",
     "cookies",
     "storage"
   ],
+  "host_permissions": ["https://kagi.com/*"],
   "chrome_settings_overrides": {
     "search_provider": {
       "name": "Kagi",
       "search_url": "https://kagi.com/search?q={searchTerms}",
-      "favicon_url": "https://kagi.com/favicon.ico",
+      "favicon_url": "icons/icon_32px.png",
       "keyword": "@kagi",
       "is_default": true,
       "suggest_url": "https://kagi.com/api/autosuggest?q={searchTerms}",
@@ -38,7 +39,7 @@
   "incognito": "spanning",
   "browser_specific_settings": {
     "gecko": {
-      "id": "search@kagi.com"
+      "id": "search@kagi-c6c861f2-d54d-43ed-9035-cbd908b8cb3a.com"
     }
   }
 }
\ No newline at end of file

Modified v0.2:

Source code:

kagi-search-for-firefox-02-2.zip

67kB

brn

Now that's confusing! Maybe something changed in that behavior with declarativeNetRequestWithHostAccess vs adding the host in permissions between v2 and v3?

And with v3 you keep losing, you don't get the same thing of the first time not working and the others working?

I'm tempted to keep calling it a bug on Firefox, unless we can find a way to fix it with manifest V3. If you want to downgrade it in Mull, you should be able to simply upload your own v2 extension and use the collection to point to that instead of the published one, no?

loloriz

And with v3 you keep losing, you don't get the same thing of the first time not working and the others working?

Nope, refresh does not work. I tried to change the session token etc, but it was completely broken.
Btw, if I check the declarativeNetRequest rules (with v0.3.7) everything seems to be fine, so maybe it really is a firefox bug.

you should be able to simply upload your own v2 extension and use the collection to point to that instead of the published one, no?

I think an unpublished extension cannot be added to a custom collection, or I can't find where to add it 😃 The custom search engine (with session token) is a half working solution.

brn

@loloriz you can install with https://extensionworkshop.com/documentation/develop/developing-extensions-for-firefox-for-android/#install-and-run-your-extension-in-firefox-for-android and yes, this seems like a Firefox but it's a bit convoluted to report and I don't see anything in https://bugzilla.mozilla.org/buglist.cgi?quicksearch=declarativenetrequest

loloriz

Some update, I found a workaround for this issue that works for my real use case (custom history settings, cookie cleanup on close, containers) on newer extension versions.

Install the extension and disable it in private mode
Exclude Kagi from cookie cleanup:
a. Go to Kagi's page, press Ctrl + I (on linux), then set cookies on Permissions tab, image
b. Go to Settings -> #Privacy -> #Cookies and Site Data / Manage Exceptions, image
Log in to Kagi (in a non-container tab if applicable)
Check the extension; if needed, paste the Kagi session token
Enable the extension in private mode.