IET11: Duplicate Tools->IET entries if installed via policy as file:/// url

[klou]

IET 11.0 TB 91.2.1

With the Menu Tool bar enabled, Tools->Import Export Tools NG shows twice, with the 2nd having an empty first sub-entry.

Neither entry appears on the hamburger menu->Tools listing.

[jobisoft]

This looks like a broken profile, as we do not support incognito mode in add-ons. Can you try in a fresh profile? Do not delete your original profile. I would like to get behind that incognito mode error later. Do you happen to have a copy/backup of your original TB78 profile, before updating it to TB91? If so, please keep that as well. Thanks!

[klou]

Yeah, it's certainly an oddity. I have a user that has the incognito mode on a single addon.

For me, I created a new profile, and it's still the same -- both incognito mode and menu entries. Nothing in my policies.json or thunderbird.cfg that would seem to trigger this, though.

I'm not sure about the TB78 profile, though. But I recall seeing the duplicate entries on previous versions of IET.

[jobisoft]

Do you have Thunderbirds offline mode enabled?

[klou]

No, definitely not Offline.

(edit: not)

[jobisoft]

For me, I created a new profile, and it's still the same -- both incognito mode and menu entries. Nothing in my policies.json or thunderbird.cfg that would seem to trigger this, though.

That is extremely odd. What OS?

[klou]

Interesting. We're chasing down 2 different things -- IET duplicate menu items, and extensions in incognito mode.

I renamed/removed my policies.json and thunderbird.cfg -- and I should be deploying addons via policies.json.

I'm actually deploying the files to %programfiles%\Mozilla Thunderbird\distribution\extensions\*.xpi and then referring to this path in policies.json for installation. However, after removing my configs, these addons are still being copied to and installed into NEW user profiles, all enabled for incognito mode. I thought that sideloading via dropping into that path was deprecated?

IET menu items exist for these new profiles. Perhaps being installed (again?) via Policy is creating another set of menu items.

[jobisoft]

So can you reach a point where ImportExportTools NG is completely removed from your system (no entries in Tools menu) and then install it the usual way and see what happens?

[klou]

So I ripped it apart a few times, removed everything, and put it all back in different permutations. And can't reproduce any of it. So maybe this is an artifact of upgraded profiles/upgraded addon.

[jobisoft]

What happens if you set browser.privatebrowsing.autostart to false ?

Thunderbird does not support private browsing, but enabling it could cause issues with add-ons.

[klou]

So, my deployment re-confirmed and deployed my configurations, and it's still showing the double menu.

However, nothing about Private Browsing with the extensions, and also browser.privatebrowsing.autostart is false (since it is a new profile).

I've ripped out my extensions.enabledScopes and extensions.AutoDisableScopes preferences, so this should be "stock" as far as side-loading extensions is concerned.

[jobisoft]

I think this is an entirely different bug, which I have seen with LookOut as well. Do you use local file:// path for the add-ons in your deployment configuration? Can you switch to https:// ? What happens?

[klou]

For the record (though I'm sure it's in your email by now):

{
  "policies": {
    "DisableAppUpdate": true,
    "ExtensionUpdate": false,
    "ExtensionSettings": {
      "*": {
        "installation_mode": "allowed",
          "blocked_install_message": "This extension is explicitly disallowed."
      },
      "[email protected]": {
          "installation_mode": "normal_installed",
          "install_url": "file:///C:/Program%20Files/Mozilla%20Thunderbird/distribution/extensions/[email protected]",
          "updates_disabled": true
      },
     "{a62ef8ec-5fdc-40c2-873c-223b8a6925cc}": {
          "installation_mode": "force_installed",
          "install_url": "file:///C:/Program%20Files/Mozilla%20Thunderbird/distribution/extensions/{a62ef8ec-5fdc-40c2-873c-223b8a6925cc}.xpi",
          "updates_disabled": true
      }
    }
  }
}

[jobisoft]

Can you confirm, that the using an https:// link to ATN resolves the issue? (I understand that you have reasons to use a file:// url, but for the sake of identifying the cause of this bug, a short test would be great).

[klou]

Very interesting, this seemed to have "fixed" it! (Or at least, found it.) I linked to Github instead (didn't want to spend the time finding the ATN link):

	"ExtensionSettings": {
			"*": {
				"installation_mode": "allowed",
				"blocked_install_message": "This extension is explicitly disallowed."
			},
			"[email protected]": {
				"installation_mode": "normal_installed",
				"install_url": "https://github.com/thundernest/import-export-tools-ng/releases/download/v11.1/import-export-tools-ng-11.1-tb.xpi",
				"updates_disabled": true
			},

Also notice the timestamps on the profile's *.xpi (most recent TB launch at 1:16PM)

edit: Even though the core filename was different, it still didn't re-install. I hope it's not because of extension ID/filename mismatches.

[klou]

FWIW, the issue also persists under MacOS. So I assume it has something to do with the (locally-sourced) extension being installed at every launch instead of checking the internal versioning.

[jobisoft]

I am reducing this issue now to the misbehavior when the add-on is being installed via policy using a file:// url. Can you check if this version fixes it for you?

import-export-tools-ng-11.2b2-tb.zip

You have to restart twice. The first restart will still fail, because the old/installed add-on which is starting up and is not properly shutting down when the new version is installed over is causing the issue. On the second restart, the new version is starting up and should now be able to cope with the early kill.

[klou]

Released XPI v11.2 has a typo in manifest.json; should be "strict_max_version": "95.0"

https://github.com/thundernest/import-export-tools-ng/blob/4504a98b585e8caeca070c2ca4dde7ca7a53821b/src/manifest.json#L11

Once fixed, it works as you say, on the second restart.

All of the file:/// URLs are still being "updated" upon every restart, though. Hopefully that's being looked at in TB-core.