NeverDecaf
Update not functioning anymore
I'm using latest version of ungoogled Chromium with firejail sandbox. Updates are announced as usual, clicking on name of extension formerly started update. Now clicking only opens a new tab (in background). Then nothing happens until the new tab is manually closed then update seems to be downloaded into download folder. Thats it! Nothing else happens. I can manually update the downloded extension by drag 'n drop into chrome://extensions/. The following is set:
If you are using ungoogled-chromium: You must change the flag chrome://flags/#extension-mime-request-handling to Always prompt for install. The following is unset: If you are NOT using ungoogled-chromium: Ensure the following option is checked: Extension Options (chrome://extensions/?options=ocaahdebbfolfmndjeplogmgcagdmblk) > Advanced > Always download CRX files
What I tried without avail: disabled all non relevant extensions, started update by right click 'update all extensions'
I get a similar issue with Ungoogled Chromium too; extensions are set to download to a folder instead rather than just updating like they normally should as per the directions in the readme lead users to normally experience. Something is amiss.
121.0.6167.184 - It's what's currently served by flathub for Linux distributions as a Linux agnostic package.
I can reproduce this issue with the following version: 121.0.6167.184 (Official Build, ungoogled-chromium) Arch Linux (64-bit)
Which version of UGC? I can't reproduce this on 122.0.6261.56
Version 121.0.6167.184 (Official Build, ungoogled-chromium) Arch Linux (64-Bit)
Sometimes update via rightclick does function!? Downloaded extensions remain in download folder anyway. Is this intended?
Can't test atm but might be an issue with chrome.tabs api, try changing lines 125-127 in util.js from msgHandler({ newTabUrl: crx_url, }); to window.open(crx_url, "_blank");
Sometimes update via rightclick does function!? Downloaded extensions remain in download folder anyway. Is this intended?
I seem to be able to update the extensions by right clicking the icon for chromium-web-store, and clicking update all.
Though I have to click the "Add extension" button 20-30 times before anything happens.
Version 121.0.6167.184 (Official Build, ungoogled-chromium) Arch Linux (64-bit)
Can't test atm but might be an issue with chrome.tabs api, try changing lines 125-127 in util.js from
msgHandler({ newTabUrl: crx_url, });towindow.open(crx_url, "_blank");
This resolves the issue here.
@kinoegit Can you please test to see if you can update the extension when it's disabled? Your extension should update successfully if you disable the extension you are updating.
Same here (manjaro, ungoogled-chromium)
@kinoegit Can you please test to see if you can update the extension when it's disabled? Your extension should update successfully if you disable the extension you are updating.
Works!
Your extension should update successfully if you disable the extension you are updating.
Didn't work for me
I don't know how, but an update of my ungoogled Chromium reset my "chrome://flags/#extension-mime-request-handling" to "default". I changed the "flag chrome://flags/#extension-mime-request-handling" to "Always prompt for install" and works again.
I don't know how, but an update of my ungoogled Chromium reset my "chrome://flags/#extension-mime-request-handling" to "default". I changed the "flag chrome://flags/#extension-mime-request-handling" to "Always prompt for install" and works again.
I tried this and it doesn't work for me. (122.0.6261.111)
Is this the same issue that where it successfully detects and starts trying to add extensions but then they get stuck in downloads as "adding to chromium" - while the download spins forever? Also when clicking the x or right clicking the download and clicking cancel has no effect; it is stuck. It open happens with some extensions, however.
Using the latest UG on Flatpak
I've also noticed opening another profile and sometimes this not happening in it, while continuing in the current profile (previously opened window/profile in UG).
Update on my experience with this issue: basically some restarts and retries of extension updates eventually gets them installed. It still only happens sometimes and it isn't clear what can cause extension download to hang / never complete. If you're having this issue, then try restarting UG and clicking the chromium web store button again to trigger the updates.
In my experience, it's consistent enough (in normal usage, not brute force attempts - though I have tried that) that I've never once gotten it to go back to its normal behavior since this issue began.
Very consistent for me too. Extensions remain stuck in "downloading". The right click + "update all extensions" trick does work for me though. Ungoogled chromium 125.0.6422.76.
try changing lines 125-127 in util.js from
msgHandler({ newTabUrl: crx_url, });towindow.open(crx_url, "_blank");
Does this fix/workaround work for any of you? @ThisNekoGuy @waldner @kinoegit
I'd like to try it, but i'm a noob so please bear with me.. I'd need instructions even with that tiny bit of code, especially how to build after changing those line(s) in util.js
@NeverDecaf can't test right now because I don't have any extension needing update, will test ASAP.
@kinoegit: decompress the .crx file into a folder (it's a zip file), make the suggested change to file scripts/util.js, then use "load unpacked" to load the extension from the folder where you decompressed it.
Okay, don't worry about testing the above fix. Instead let me make sure I fully understand the issue first:
- The problem is: installing any extension from the popup menu or web store downloads the CRX instead of prompting to install the extension.
- The flag
#extension-mime-request-handlinghas been set toAlways prompt for install - The
Always download CRX filescheckbox in chromium web store options is not checked.
If all of these are true, then I've prepared 2 slightly modified versions of the extension you can try and see if they fix the issue: cws-test-A.zip cws-test-B.zip Please test A first and only try B if A doesn't work. (If you can't install crx files with drag&drop, you can use the "load unpacked" workaround described in the comment above this one.)
Notes for posterity:
Both versions only modify this line, A and B remove the tabs.update and B sets active: true I'll also mention that I have a vague memory of chromium disallowing CRX installs from most URLs (which would cause the behavior described by this issue), it's possible that the build I'm using has been compiled with a special patch to make this possible, though I'm fairly certain that patch would be the one that adds the #extension-mime-request-handling flag in the first place...
My experience (without trying your new patches) is that a background tab is opened, the extension gets downloaded (because I see the file appears on disk), but then the download icon keeps spinning, the download never finishes, and it cannot even be interrupted by clicking on the X button.
That's really strange... it sounds like a browser issue that's independent of this extension. The only thing that happens when you update an extension by clicking in the popup is that your browser opens a url in a new tab. Here is the uBlock url that would open, for example: https://clients2.googleusercontent.com/crx/blobs/AcO95oh11uHb5009Xya0VZQmSlSj81IfJLi8Ai01-01SLLk5PKQnNmaKxflEjToRfXpzcGcUuUBDdER4P_SJ1DmeQURAwBPqfmHtnKScv2U2qGj9RQNEUcqhZ241tHg10Vf0AMZSmuWQVmmt0hbH8B_6jziS-MOD5cTcxg/CJPALHDLNBPAFIAMEJDNHCPHJBKEIAGM_1_58_0_0.crx Can you try visiting this url in your browser to see if it prompts for install correctly?
Yes that works and I'm prompted to install it. As soon as some extension need updating, I'll test your new version of the addon.
As a matter of fact, one addon became updatable shortly after I wrote this, so I tested with the original cws extension and I got the buggy behavior; I then uninstalled and installed cws-test-A and that worked. Unfortunately I don't have another updateble addon now, so I couldn't test cws-test-B. But cws-test-A seemed to work fine.