This is happening (or not, I guess) on a fairly fresh re-install of 15.3+updates on my older Dell laptop. I do not have this problem on the same releases running on my primary desktop system.

The desktop system that is successfully installing add-ons is using a wired network connection to local switch where the LAN firewall is connected. The laptop is accessing the 'net via a WiFi router connected to the same switch. (Offered for completeness; I do not suspect the network is the culprit.)

In both cases, I'm using a downloaded copy of FF (100.0.2) from the Mozilla web site. (Coped from my desktop system---same architecure: x86_64.) These are installed under '/opt/app/firefox' and a symbolic link in '/usr/local/bin' points to '/opt/app/firefox/firefox'.

I can get to the Add-On 'store' and select an add-on but when I click to proceed with the install, a 'busy' icon simply spins and spins and spins (well, not exactly spins---it's more like an old Cylon eye). Eventually, after several minutes of doing nothing, I have to kill the tab running the add-on install process. It doesn't matter which add-on I try, the end result is always the same: the web page looks busy but nothing is ever installed.

The few suggestions I've found on the 'net (from a few years ago) tell the reader to go into about:config and ensure that 'javascript.enabled' is 'True'. Which it already is.

Other things I've tried:

• Running FF via strace and watching to see what is happening after clicking on "Add to Firefox". Not much I can glean from the (yikes!) 46+MB of output other than it appears that FF tries to deal with a crazy number of fonts at startup and then examines the system clock obsessively.
  
• Renaming '~/.mozilla' on the laptop, launching FF, and comparing what directory structure and permissions are created against what's working on my desktop. Odd that on my desktop where add-ons can be installed, I have:
  
  Code:

  .mozilla/
     +---firefox/
        +---74e6kj42.default-release-3/   <-- there are multiple dirs like this from previous versions/upgrades
            +--- other directories
            +---extensions/
                 +----add-on-foo.xpi
                 +----add-on-bar.xpi
                 +---- etc

  whereas, on the laptop -- after renaming the original '~/.mozilla' to '~/..mozilla' -- I get:
  
  Code:

  .mozilla/
      +---firefox/
            +---<user-account-specific-dir>
                +--- other directories
      +---extensions/   <-- empty after installation attempt

  Why the 'extensions' directory would be located outside the profile directory is a mystery. Same OS release, same version of FF, but different setup after running it for the first time than what I'm seeing on the desktop (where add-ons can be installed).
  
  The laptop directory structure looks (AFAICT) pretty broken after being created anew. It is, however, the same directory structure that was there before renaming the original '~/.mozilla' tree out of the way and launching FF.
  
• After backing up the laptop's '~/.mozilla' directory, I moved the 'extensions' directory into the same location I find on my desktop system. I still cannot install add-ons. I also tried copying the '.xpi' files from my desktop to the 'extensions' subdirectory on the laptop. Then, when I launch FF, I see a message that add-ons were installed. But... they're not enabled. When I attempt to enable them, nothing happens---the add-ons manager tab just hangs.
  
• Moving the '.xpi' files to some random directory and trying the 'install add-on from file' method, the tab hangs in the same way. Re-downloading them from the Add-On site to '/tmp' on the laptop and attempting to install from those files has the same result: hung tab.
  
• One of the suggested workarounds found online (on Mozilla's site, no less) was to drag-n-drop the add-on file onto the Add-Ons manager page. While this initially appears that it might work, all it does is pop-up the same dialog box to 'Cancel' or 'Add' the Add-On. Clicking on 'Add' has the same result: hung tab but without even showing any indicator that's it's even trying.
  
• Finally, this doesn't appear to be specific to 100.0.2. I downloaded the latest FF from the Mozilla web site (102.i-forget) and I'm seeing the same non-install problem.
  

It appears to me that the Add-Ons management function is broken in some way. Missing library perhaps? I would expect this to cause either a spectacular failure or log an error message somewhere, though, and not just go catatonic.

Has anyone got anything else I ought to look into? I'm stumped at this point.


TIA...

Why that and not using the /home folder for installing?

Why not using Firefox from openSUSE OSS- or -Mozilla-Repo?

For consistency with my desktop system which has multiple user accounts on it: me, postgres, plus some others. All of those will need to use FF at some time or another. I only have a couple of accounts on the laptop but installing it the '/opt/app' filesystem with a symlink to it in '/usr/local/bin', as I do on the desktop system, makes it available to all accounts.

Because it is always several versions out of date. It is stuck on V91.11.0 when I checked a while ago. I suspect that when I update the two systems to 15.4, the repository will still be behind on FF patches and updates. My original reason for moving to the downloaded FF tar archive from Mozilla was that I was unable to install add-ons for the V91.11.0 installed from the openSUSE repository.

You can put profiles anywhere you want them. What controls profile names and locations is ~/.mozilla/firefox/profiles.ini.

Just now I:

1. installed Firefox ESR 102.1.0 on
   Code:

   inxi -GS
   System:
     Host: asa88 Kernel: 5.3.18-150300.59.76-default arch: x86_64 bits: 64
       Desktop: Trinity v: R14.0.12 Distro: openSUSE Leap 15.3
   Graphics:
     Device-1: AMD Kaveri [Radeon R7 Graphics] driver: amdgpu v: kernel
     Display: x11 server: X.Org v: 1.20.3 driver: X: loaded: amdgpu
       gpu: amdgpu resolution: 1920x1200~60Hz
     OpenGL:
       renderer: AMD KAVERI (DRM 3.39.0 5.3.18-150300.59.76-default LLVM 11.0.1)
       v: 4.6 Mesa 20.2.4

   in /usr/local/ff102
2. created a new profile for it with my text editor
   Code:

   [Profile4]
   Name=ff102
   IsRelative=0
   Path=/<filter>/ff102

3. added /usr/local/share/applications/Firefox102.desktop containing:
   Code:

   [Desktop Entry]
   Categories=Network;WebBrowser;GTK;
   Comment=Web Browser
   Encoding=UTF-8
   Exec=/usr/local/ff102/firefox -no-remote -P ff102
   GenericName=Web Browser
   Icon=firefox
   MimeType=text/html;text/xml;application/xhtml+xml;application/vnd.mozilla.xul+xml;text/mml;application/x-xpinstall;x-scheme-handler/http;x-scheme-handler/https;x-scheme-handler/ftp;
   Name=Firefox ESR102
   StartupNotify=true
   Terminal=false
   Type=Application
   X-KDE-SubstituteUID=false
   X-KDE-Username=

4. opened the fresh Firefox from main TDE menu
5. smoothly and successfully used add-ons manager to install and enable uBlock Origin

I rarely use distro builds of Mozilla products, which I've been using since long before switching primary OS from OS/2 to openSUSE, and before there were any thoughts of a Mozilla product named Firefox.

Use the Mozilla Repo and you get the newest one:

openSUSE OSS uses the latest ESR Version of Firefox and this one get every patch as the others.......

The other reason for using Mozilla's builds is it makes possible installing as many different versions at once as you choose, and running them all at once if that's your pleasure, and you're capable of corresponding profile management. If in the website construction and/or maintenance business, this can be a crucial capability. It's also pretty important to those who alpha/beta test Mozilla products.

I don't see much difference between your setup in '/usr/local/ff102' and mine in '/opt/app/firefox-100.0.2' (or the recent trial where I installed it in '/opt/app/firefox-102.0.2').

I can try something like that on the laptop this evening. I'm still wondering, though, why the same OS and the same Firefox download would behave so differently on two systems that aren't all that different architecturally (Celeron vs G3440 ... both 64-bit).

If nothing improves by the end of this weekend, I may bite the bullet and do a re-install on the laptop (ugh... the Broadcom firmware hassle again) though I have doubts that that will do much.

Interesting. On my desktop system, YaST is only showing the 91.11.0 package as the latest available. Even Tumbleweed (on a system I applied updates to yesterday) only shows 102.0.1. I'll have to check into this disparity.

But... bottom line: having the latest and greatest Firefox is not the problem. The difference in the way the same version is working on the two systems is the problem.

Thanks, though. I'll look into changing the way I get FF on the laptop to use the Mozilla repository to see if that changes anything.

My response was primarily directed at profile management, but I wanted all possibly relevant details included.