Upgraded 60.9 to 68.2 - all extensions gone and or keep going away (profile stored on Samba network drive with outdated Samba version)
Categories
(Thunderbird :: Add-Ons: General, defect)
Tracking
(Not tracked)
People
(Reporter: abittner, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:52.0) Gecko/20100101 Firefox/52.0
Steps to reproduce:
(I am on german locale systems, so not sure if I am right with all the naming of intl./english Mozilla components, functions and buttons etc.)
Odd problem with several TB instances (windows7pro x64 upgraded slightly before to win10pro x64). everything on x64 windows, german. german TB as well.
Thunderbird 60.9 32bit was running before with a number of happily working extensions, for example lightning (builtin/standard by mozilla I guess), for example quicktext, dkim verfier, lookout (fix version), lookout and warnattachment.
Basically, after the upgrade to 68.2 (via the about dialog box), during the first boot/startup of Thunderbird, going to extensions area, behaves weird, all(?) lot/most of the extensions briefly lit up, flickered and then vanished, completely, sometimes (some machines) the lightning would stay visible, but disabled/greyed colors. Most extensions would simply not be listed any more.
During this first reboot into the 68.2 TB, searching for example for lightning in the extensions area search bar, bringing up a new tab of the AMO website within TB, would show lightning as compatibly listed, and I could select it from there to be re-added, it would download and briefly become loaded/activated on the upper right corner of the TB window as whole, asking to be confirmed.
Then the lightning area would briefly show up on the right side of the whole TB window, with todays pane or whatever default view, but the TB extensions area would still display a message the TB needs to restart to make lightning start working, even though it was already being executed and apparently working.
On the second and every other restart/startup of TB, the lightning extension would again be not working any more, greyed out, or sometimes not listed any more, there are a lot of variations to this, depending on which machine etc. situation exactly.
Bottom line is, lightning would kind of be the only extension that is left, or mostly not even this stays working.
All other extensions are vanished, but for example very briefly if my mind and eyes are not playing tricks on me, during initial visiting of the extensions area within a freshly started TB, they briefly flicker into visibility for a fraction of a milisecond or something just to disappear again. Not greyed, not visible. No nothing except for flickering once.
Also AMO website inside TB does not list me for example dkim or lookout or warnattachment as hits/results at all, not being compatible or not being given as a valid result seem to be the situation here.
My gut feeling tells me that maybe this upgraded TB kind of sends or uses the wrong version number to talk to AMO via its apis or however this stuff works. I cant really think of much else. Somethings become stuck and misinterpreting things and situations here.
I also have happily fine and nicely working upgraded 60.9 to 68.2 TB situations on win7 and win10 both. So I cant really tell whats happening.
Also, when visiting the about:preferences or configurations area of thunderbird on the affected machines, I see lot of entries/variables/settings being listed when i search/filter for example for this quicktext, warnattachment or dkim or similar stuff, or extension as string in general.
So the profiles and configs affected, do seem to have relevant settings and data still there and stored.
Actual results:
Initially, on first install/restart of the upgraded 68.2, it triggered the default browser to show some technical and informational stuff about TB changes, there I read a number of articles about vanishing extensions or nonworking lightning of various kind, and there was some GUID or some long number listed, I cant recall the exact place and article any more, but I did search and find that line in TB config and set it to default or something as the article claimed, but that only briefly solved the lightning situation that on one machine the lightning now stays constantly in the extensions area but always greyed out, deactivated, and I can select activate but it shows in orange text that TB needs to reboot and it does not come back as working lightning after the reboot of TB, so that doesnt really help in real functionality, only kind of the extensions area get slightly repaired state considering lightning only, but barely.
Expected results:
extensions should all work normally after an upgrade from TB 60.9 to 68.2.0 on all installations
|
||
Comment 1•6 years ago
|
||
I few points to consider here.
AMO - Add-ons Mozilla . ORG is for Firefox extensions: addons.mozilla.org.
ATN - Add-ons Thunderbird . NET is for Thunderbird extensions: addons.thunderbird.net.
When you upgrade, it's possible that some extensions are no longer available since the authors haven't supplied a compatible version.
For the ones you mentioned, the situation is this:
quicktext - https://addons.thunderbird.net/en-GB/thunderbird/addon/quicktext/ available
dkim verfier - https://addons.thunderbird.net/en-GB/thunderbird/addon/dkim-verifier/ available
lookout (fix version) - https://addons.thunderbird.net/en-GB/thunderbird/addon/lookout-fix-version available
warnattachment - https://addons.thunderbird.net/en-GB/thunderbird/addon/warnattachment/ not compatible.
All that said, I did an upgrade once for a friend and I had the impression that add-ons didn't get updated properly. Andrei, do you have any insights?
|
||
Comment 2•6 years ago
|
||
(In reply to Jorg K (GMT+2) from comment #1)
All that said, I did an upgrade once for a friend and I had the impression that add-ons didn't get updated properly. Andrei, do you have any insights?
This is so vague and lengthy I can't really tell what's going on. If I had to guess, though, it would be Bug 1574183.
|
|
||
Comment 3•6 years ago
|
||
Right, just the answer I wanted. I should read that bug more carefully and add a release note as was suggested.
Uhm, I dont understand :( Sorry if my bug was too confusing or not precise, also I am not a complete noob. I definitely have broken Thunderbird 68.2.1 installations by now, where not one single addon can be permanently installed. And all addons seem to be restart-needing addons. Even lightning, and I know that lightning isnt usually needing arestart at all. Nor lookout (fixed) nor dkim verifier..
I also cleaned all those extensions config files etc as stated in various support mozilla(tb) articles
extensions.sqlite
extensions.sqlite-journal
extensions.ini
extensions.json
Even when installing via .xpi file e.g. lookout@s3_fix_version.xpi from the desktop
this lookout doesnt stay active ever. Not after reboots of TB, not after clicking activate onto lookout in the extensions area and it then telling me over and over again that I need to restart TB etc.
Lightning is the only extension that coming from AMO, from inside TB 68.2.1, is installing itself into TB and appearing live in the still running TB on the right side of the main TB window, and still never the less asking for a TB restart. After restarting TB 68.2.1 the lightning extension is again disabled magically and can not be made to run again at all except for removing it completely and starting this over again :(
In the TB profile directory, there are eventually also folders named "browser-extension-data" and "extenions" where e.g. lookout.xp and some stuff briefly appears as files in there, but I even deleted those two folders and their subdirectories to make it recreate those things as well, and it all doesnt help.
This bug all started when TB gave me the upgrade from 60.9 to 68.2.0.
I have several machines with these symptoms, but several others dont have these problems.
Please help. Thanks.
how can I help?
any about:config (configuration editor) values or other config stuff needed or something?
thanks for debugging this situation.
Just wanted to make very clear that my bug, methinks at least, is not at all a duplicate of that other bug
( Duplicate of bug: 1574183 )
i am not a noob unable to reinstall my extensions/addons, but no addon/extension would ever stick and work in the newly updated 68.2
The only solution I found was to uninstall 68.x and revert back to 60.9, there was another phenomenon that apparently yet again incompatible extension were residing inside the hosed Thunderbird installation and all greyed and inactive, but I could remove them there as well, and just re-select them via AMO and they would be brought back in a functioning state in the 60.9.x again.
There is something deeply messed up every now and then when migrating from 60.9 to 68.x
:(
|
|
||
Comment 7•6 years ago
|
||
Wayne, I think this will be trouble for the 60 -> 68 transition. (NI just to attract attention.)
|
||
Comment 8•6 years ago
|
||
If it really is a Duplicate of bug: 1574183 I don't know what we can do - someone decided that bug would not be fixed or 68. Super crappy UX.
If it's not that bug, as stated in comment 4, I don't know that we've seen other reports of this.
|
|
||
Comment 9•6 years ago
|
||
Bug 1574183, indeed (the colons destroys the linkify). No idea why this was de-duplicated.
|
||
Updated•6 years ago
|
|
Reporter | |
Comment 10•6 years ago
|
||
I think I found something of a detail about this Bug. The affected machines all have their userprofiles (TB profile) on a networking drive (samba share, network share on a windows machine as the share server). The network share is properly established as a windows drive letter (network drive letter).
And yes, everything still works fine with 60.9, no things changed on the networking or server side.
What I have discovered is that the 68.3.0 (x64 windows 64bit build by now even tried that) installation does not manage to write especially .json files, meaning that I have plenty of json.tmp files, but they seem to remain and never be switched over or finalized into .json target/final state files.
I have extensions.json.tmp file rather big, with 65kbytes on one affected machine, but no extension.json in any kind of circumstances / states of the application. Not after shutdown of thunderbird.exe not ever.
Is it possible that json or config file writes especially have been changed in the source code or some kind of algorithm to write these config files has seriously been changed from thunderbird 60.x to 68.x?
Whenever I revert back to thunderbird 60.x everything is immediately fine again :(
Can anyone test and repro this with the help of a network drive smb share and a fresh profile and selecting just a few of extensions such as lookout (fix edition), warn attachment, dkim verifier and lightning calendar or any kind of simple extensions?
I guess no mail files or actual mail config would be needed at all.
|
|
Reporter | |
Comment 11•6 years ago
|
||
I further narrowed down this issue: at both places (disjunct networks) that express this bug in TB, there is a windows server 2008 R2, with samba networking set fixed to samba protocol level version 1 (one) smb v1, due to some limitation of legacy software in the networks :(.
On these networks, thunderbird 60.9.x worked perfectly fine with addons etc, but around october/november 2019 when TB decided to upgrade over to 68.x functionality of addons went haywire.
Today I was able to disable samba version1 and set it to default values, then windows server 2008 R2 resorting back to default of some samba protocol level of 2 and above. The windows10 client machines with the thunderbird 68.x and their profiles on that samba network drive were suddenly working fine again. Unfortunately I can not really go for this way in at least one of the affected networks/places.
Side note: still while having samba smb version 1 and TB 68.x, I found lots of those .json.tmp files in the profile directory, and they allmost all had no siblings or parents or collisions so I could simply rename them to .json (removing the .tmp) and then fire up TB 68.x again, and even with smb version 1 and starting up Thunderbird 68.x this way, I was briefly able to use all the addons etc, as long as I didnt shut down TB again. As soon as TB exited and quit, it again created those .json.tmp files on the network drive with conjunction of samba protocol version 1 and would not properly name/rename/copy over its .json.tmp files to .json named files.
As soon as going with samba version 2 on that network share, TB 68.x would not even create or leave .tmp named files in the profile directory at all, or just one single one that didnt cause any problems, I think it was some filename related to shutdown or startup performance and times or whatever, but all the extensions and addons etc. files namend .json.tmp would stay .json and never end up in faulty states and situations.
So Thunderbird definitely did some algorithmic or programming changes how its handling its config .json files or their updated versions and temporary states, ending up in .json.tmp files and staying as such, and TB 68.x failing in such circumstances where TB 60.9 would still work perfectly.
I know that samba protocol version 1 is old and outdated, insecure and whatnot, that is beyond this bug report. Wondering if new TB versions could be made work nicely with old samba network shares just as well as older TB 60.x etc.
Thanks.
|
|
||
Comment 12•6 years ago
|
||
Thanks for the update. If I read the previous comment correctly, it's all working with Samba version 2, right?
Please understand that the Thunderbird software consists of approx. 95% Mozilla platform code 5% mail specific code. Mozilla platform code is also the base for Firefox and handles these functional modules, amongst others: Networking, file access, non-mail databases (certificates, security, history, etc.). most of add-on processing, graphics, rendering the UI and message content onto the screen, and many, many more.
So Thunderbird definitely did some algorithmic or programming changes how its handling its config .json files ...
I'm 99.995% sure that Thunderbird didn't make any changes in that area, but it's very likely that something in the underlying Mozilla platform code changed. So if you want to pursue the matter further, you'd have to see whether this is reproducible with add-ons in Firefox. This could be tricky since Firefox only supports so-called WebExtension add-ons these days, whereas Thunderbird also support "legacy" restartless and overlay-based add-ons.
Overall, I don't think this bug will be addressed, especially since everything works with a later Samba version.
Geoff, just out of interest, does C-C or M-C code do the JSON file handling mentioned in comment #11?
|
||
Comment 13•6 years ago
|
||
This is definitely Mozilla code and it's possible something has changed deep inside their file-handling but I'm not aware of anything.
|
||
Comment 14•6 years ago
|
||
When I have time over the coming weekend,
I will take a look at this because my Wi-Fi router at home has this nifty feature of using USB memory as a temporary file storage mountable via CIFS/SAMBA and I am sure it is an old SAMBA 1.x. (The Wi-Fi router seems to run a version of linux inside.)
I tested TB against this CIFS/SAMBA mount for lots of I/O-level issues to weed out pop3 and short read problems. (I have yet to merge them into C-C tree.)
It would be interesting to see how the latest TB code behaves against profile stored there.
I think it is still important to support CIFS/SAMBA 1.x due to the fact that there are many SOHO and SMEs (small and medium enterprises) where s NAS boxes are used and some of them are very old and only support SAMBA 1.x.
For that matter, even CIFS code under linux is not bug-free in terms of SAMBA support (I subscribe to linux-cifs mailing list to keep track of the current status), and so I am not sure where to put the blame here...
Open source is wonderful when it works, but when it doesn't, it is really difficult where to begin to solve the problem.
Description
•