IceDragon Extensions Wont Run Inside Container

IceDragon Extensions Wont Run Inside Container

Not sure if this is the Desired Behavior with Comodo Firewall v. but it appears to be related to the following bug, which Mozilla is currently working on:

I have successfully applied the fix within Firefox by temporarily enabling Firefox to install and run studies in Tools>>Options>>Privacy and Security.

The interesting thing is that in IceDragon, running outside the container, all is well. No fix is necessary. Inside the container, however, no extensions will run.

Please refer also to the following thread from the NoScript extension forums:

Scrolling to page 2 of the thread, near, the bottom, is the following post from the Extension’s creator, George Maone:

Re: Firefox deactivates NoScript...and calls it Legacy

Post by Giorgio Maone » Sat May 04, 2019 12:23 pm
They've started deploying the hotfix.
Notice that if you're the typical NoScript user, you probably have Firefox Preferences>Privacy & Security>Allow Firefox to install and run studies disabled, but it's currently (temporarily) required for the hotfix to work.

If you're a Tor Browser user, you cannot enable Studies (for obvious reasons), but you can still (until this is properly and generally fixed)

    Open about:config
    Toggle the value of xpinstall.signatures.required so it becomes false.
    Restart the browser.

Giorgio Maone -- Hackademix
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:67.0) Gecko/20100101 Firefox/67.0

Toggling the aforementioned xpinstall.signatures.required value inside of the Contained IceDragon browser and restarting the browser DOES allow the extensions to run, but this is most certainly not a long term solution.

(It is not necessary to change the value inside of the non-contained instance of IceDragon).


Another unexpected behavior this morning (May 4) is that bookmarks saved while working with IceDragon inside the container do not update the bookmarks in the non-sandboxed iteration of IceDragon. Prior to this morning, the added bookmarks were being copied over.

Is this the desired behavior?


You are going to have to wait until Mozilla rolls out the permanent fix to see if it still occurs, as you have said it works when you enable the flag.

As for changes made to contained browser not persisting to non-contained browser, yes it is by design for v12 to no longer share same browser profile data between the two.

Thank you, futuretech, for your response, and your explanation about the changes in version 12 of the Firewall. I guess I will be utilizing export/import often for the bookmarks. I get the change, albeit somewhat inconvenient. Might you be able to suggest a simpler way to sync the two?

Also from your response, I infer that it was not a planned behavior on your end to have the IceDragon extensions disallowed from within the container. Correct?

Lastly, as an FYI, IceDragon extensions are now not being allowed to run outside the container as well as within it.


You have to figure out which file bookmarks are saved in with firefox and do that for Ice Dragon, then add it to the Do not virtualize access to the specified files/folders auto-containment setting. This was done automatically in v11 for each installed detected browser.

Can you point me to a thread/walkthrough on that so I don’t make you explain it all again in more detail?

I am more concerned about the other issue at this point in time, and as you stated, I will report back if I am still experiencing the issue in IceDragon when the Firefox permanent fix is in, so IceDragon developers can apply the fix to the best browser on the planet.

My only options at this point with IceDragon are:

A) Toggle xpinstall.signatures.required to “False”


B) Toggle javascript.enabled to “False” to block all scripts.

Against my better judgement, I am currently employing option A.


I did link the help page which shows you how to add files/folders to virtualization exclusion, just continue down the page. You just need to find the file/folder where Ice Dragon stores the user profile and bookmarks.

So you did… My apologies.

Now, as to the issue at hand. There is a fix, which works in the non-contained iteration of IceDragon, but not in the contained one:

Re: Firefox deactivates NoScript...and calls it Legacy

Post by Giorgio Maone » Sat May 04, 2019 8:54 pm
If you're experiencing this right now on Firefox, do this for the hotfix to immediately apply (it happened to me minutes ago on my main profile):

    Open about:config
    Turn app.shield.optoutstudies.enabled to true (if false)
    Turn app.normandy.run_interval_seconds to 1

As soon as you can see all your add-ons coming back (it should happen right away), reset both preferences.
Giorgio Maone -- Hackademix
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:67.0) Gecko/20100101 Firefox/67.0

Please advise of steps to take to apply the fix to the locked down (contained) version of IceDragon. Thank You.

Whatever changes you make to the non-contained IceDragon will also affect when IceDragon runs in containment. But you can do the same changes inside the container if it doesn’t work.

The changes that were made inside the non-contained IceDragon (that worked) had no effect upon the contained IceDragon.

When the changes were made directly inside the container, they had no effect and did not work.

All extensions remain broken within the contained IceDragon browser. This includes the Comodo Https Enforcement extension.


A full uninstall and subsequent reinstall of Comodo Firewall 12, Comodo Dragon, and Comodo IceDragon appears to have resolved the issue.

Thank you.

Thanks professor penguin for posting Georgio’s quick fix. Firefox was also updated today to v.66.0.4 to solve the extension problem which was a major inconvenience for a lot of people. Now I wonder when Comodo will update ice dragon to include Mozilla’s fix.

Thanks CommodoUser201 for the heads up, I just applied the update. All things considered, this was a very timely response from Mozilla on this issue.

Long Live Open Source.