1303715 - Remote image 'Options' button missing {Thunderbird uninstaller failed causing this issue}

Status: RESOLVED INVALID

(Thunderbird :: Untriaged, defect)

Description

[Anje]

User Agent: Mozilla/5.0 (Windows NT 6.0; rv:48.0) Gecko/20100101 Firefox/48.0
Build ID: 20160823121617

Steps to reproduce:

Reporting bug as problem was reported in support forum.
See conversation here;
https://support.mozilla.org/en-US/questions/1134777?

Background
Problem occured on Windows 10 64bit machine. OS was already installed - not an upgrade.
Person used 'Moxbackup' to get an older profile from a Win7 (upgraded to win10) machine, which had been using Thunderbird since the days of at least version 3.1.7 into the new Windows 10 computer.




Actual results:

Profile migrated ok, but new problem occurred.
The remote options button was missing.
Advised to uncheck hardware acceleration and access 'Config Editor' to check:
permissions.default.image  to see if a value was set.
It was set as 'User Set' value 2.
Person attempted to set value to '1' and also to right click and choose 'reset' option and restart Thunderbird.

permissions.default.image was not set in the 'prefs.js' file, which was expected if using default, however, it was shown in Config Editor as User Set value 2 upon restart.

changing the value to '1' allowed display of 'Options' button, but only whilst in that session.
Restarting Thunderbird always reverts to a value of '2'.

Tried restarting in Safe mode - no change.
Confirmed that other values were being saved ok to prefs.js' file.
Noted that in 'Addons Manager' - 'Talkback' was disabled and incompatible.
Whilst 'Talkback' was mentioned in 'Addons', this had not been put there by Person, it must have come across/appeared during the migration.

Tried inserting a 'user.js' file with attempt to force a value of 1 - no change.
Tried uninstall followed by reinstall - no change.
In profile name, located a 'prefs.zal' file inserted by Mozbackup - removed it - no change.

Asked person to check was in the Thunderbird program > default > prefs folder.
According to my version, there should only be 'channel-prefs.js' file.
Person reported that there were several *js files. See list below.
all-l10n.js
all-thundrebird.js
channel-prefs.js
composer.js
mailnews.js
mdn.js
smime.js

With exception of 'channel-prefs.js', I thought this to be odd, as I believed all of those js files should be in 'omni.ja' file in same location as the thunderbird.exe.
I believed something had gone wrong with the installation.

Person had tried several reinstalls of Thunderbird, but was also reporting that they had an error message.
'Update failed - Something is preventing Thunderbird from updating securely- please make sure you are using the latest version of thunderbird'.

Asked the person to use standard method of computer uninstalling via Control Panel > Programs and features - Person had expected it to be uninstalled, but I asked them to check the Program Files(x86) folder to see if TB  really had uninstalled.
Thunderbird had not uninstalled. 
So when reinstalling it seems as if there were sections of different versions functioning at the same time.
Perhaps, this was causing an issue where the default could not be reset.

Asked person to:
clear all cache, session etc.
make sure there is no mention of the user_pref permissions.default.image in prefs.js  file.
Manually remove 'Mozilla Thunderbird' folder containing program from C:\Program Files (x86)
reinstall a fresh up to date version.
Restart Thunderbird

This proved successful.



Expected results:

Whilst I do not have all info, would it be reasonable to think that the uninstall failure resulting in old and new files being present in the program could have created some kind of loop resulting in a failure to reset this particular default, which only worked whilst in that session.

In bug report https://bugzilla.mozilla.org/show_bug.cgi?id=736045
Comment 39, 47 and 49 all indicate that reinstalling 'on top of' fails to fix, but installing to different directory or manually uninstalling then reinstalling works.

This looks like the 'uninstalling' and 'installing on top of' processes failed. 
Could this be an issue with 'uninstall' not uninstalling or not installing correctly when done 'on top of'  thus leaving files that then cause this 'options' button issue?

Comment 1

[Jorg K (CEST = GMT+2)]

Sorry, we don't take support cases here.
'Moxbackup', you mean perhaps "Mozbackup", is not a tool we support or endorse.

If uninstalling doesn't work, delete the folder from Program Files manually.
If in doubt, start with a new profile.

Comment 2

[Anje]

re Comment 1: 'Sorry, we don't take support cases here.'

I know. This is bugzilla and not the Thunderbird forum.
I'm not asking for support.

re Comment 1: 'If uninstalling doesn't work, delete the folder from Program Files manually.'
I know. I actually said that in the above details and it resulted in a fix for the user.

You seem to have missed the whole point of this bug report regarding the uninstaller.
I'm reporting a load of findings which shows a problem with uninstalling.
This leaves older files in various parts of the program.
The installing of new ends up installing on top producing a load of mixed folders, some duplicates in different parts of the directory.
In this case, it ends up not allowing a particular default setting from being set beyond using in that session. The result which the user first knows of an issue, means the user has no 'Options' button for remote content each time they start thunderbird.

So what started as an issue of no remote Options button showing, was progressed to only showing during a session after manually setting a default to 1, but this was not saved beyond the session.

The root cause started with the uninstall not functioning. 
If the uninstall worked then this issue would not have arisen.

As this issue has raised it's head few times, I thought some info on what was discovered would be useful.

So, I was reporting what seems to be a bug with the Thunderbird uninstaller not doing it's job.

Comment 3

[Anje]

As this bug report was marked as 'Resolved Invalid' do I assume you are not interested in knowing about the Thunderbird uninstaller failing to function on occasions, nor the issues that arise as a result?

Comment 4

[Jorg K (CEST = GMT+2)]

Let's get a few things straight here:

1) The uninstaller is not Thunderbird software, but it comes from Mozilla core.
2) I uninstall TB Daily every few days and I have never seen a problem.
3) We cannot pursue any bug that starts with: User used "mozbackup" since this
   tool is not approved by Mozilla.
4) You know that the use of the config editor will also void your warranty.
4) If you can present clear steps to reproduce the problem, we are interested or we will
   refer the matter to the Mozilla core people.
   What you describe in comment #0 is a support case:
   User did this, and then this, and then used some 3rd party software and
   got himself into a real mess.

(In reply to Anje from comment #2)
> So, I was reporting what seems to be a bug with the Thunderbird uninstaller
> not doing it's job.
You're reporting problems with an apparently messed up installation and say that it *seems to be* a bug.

Repeating: Get us clear steps to reproduce and we'll look into it.

Comment 5

[Anje]

Sorry, I was not aware that using Mozbackup to replace a profile (which worked perfectly except for not able to reset one default other than in a session) was actually doing something in the Thunderbird program installation files which rendered the Thunderbird program uninstall to fail.

Comment 6

[Jorg K (CEST = GMT+2)]

We don't know that Mozbackup does. We are still awaiting clear steps to reproduce this problem.

For all I know, some files in "Program Files" were locked and couldn't be removed. It could be anything but a problem with the uninstaller.

Repeating: As long as there are no STR, it's a support case.