Upgrade from TB 78 to 91.1.2 leads to invalid / "orphaned" tabs

[tlhackque]

Upgraded from TB 78 to 91.1.2.
My quickfolders tabs now all show a "broom" icon on the left. Clicking on them goes to the folder, as expected.

But dragging a message from Inbox to the tab fails, and hovering over the tab produces a tooltip "No folder for [] - try the 'Find Orphaned Tabs' command."

That command says it will remove tabs with no folder assigned. But obviously, the folders exist, so I don't want to do that..

Prior to the update, dragging to the folders worked as expected.

This happens with ALL of my quickfolders tabs.

The folders in question include (several) "Inbox" folders; all of them exist. All are IMAP.

Checking for updates under Add-Ons says I'm up-to-date.

FWIW, quickfolders commands -> tab-specific properties is active - but nothing happens.

I'm not using the Pro version - the "advanced features" aren't helpful for me.

[RealRaven2000]

i am currently out of office until Wednesday.
Can you export your folders ( from the license tab - including tabs). Then replace one of the tabs by dragging the original folder from the file tree (e.g. if you have your inbox up there drag it in again). then export again so I can see the difference.

my guess is that one of your root URIs was encoded differently through the upgrade.

[RealRaven2000]

I edited the previous comment substantially - as I am on the road I can only access github through my mobile phone so it's tricky. please read on your browser as email notifications do not send any amendments

[tlhackque]

Thanks for the quick response!

I did what you suggested for my first inbox - removed the tab, then dragged it back and re-positioned it.

All the "broom" icons disappeared, and dragging to one of the other tabs works again.

I did a diff of the two .json files.

The first folder (the one I removed and replaced) gained a property "icon": null.

The others all added "invalid":true. Some already had "icon":null, but not all. I don't see any reason for the "invalid":true - the folders are all there, and accessible from their quickfolders tabs.

No URI or other changes.

To help with diagnosis, here is the data that I gathered:

A screenshot of the first few chunks. (the other folder's have the identical change).

And here is the full config file after I did the remove/replace.

QuickFolders-Config-after.zip

Let me know if you'd like more data. I'm holding off updating a second machine, so it would be possible to see if a fix make that update work properly..

[snafu1282]

I can confirm the issue, but I can also confirm that simply removing the Inbox QF tab and re-adding it seems to fix the issue.

[RealRaven2000]

I can confirm the issue, but I can also confirm that simply removing the Inbox QF tab and re-adding it seems to fix the issue.

OK, so from what I hear is that the test algorithm that checks validity of URLs can be confused by the upgrade from 78 to 91, which is peculiar because the internl storage of the folders hasn't actually changed, nor has the algorithm. But the folders are still stored in Thunderbird's internal configuration database (physically that is prefs.js), so my best step forward would be to move it into an external JSON file, just like the QuickFolders reading list already is stored in an external file.

I will have to confirm with @jobisoft what the most standards-compliant way to do this is so that converting to an API- based "true mail-"extension doesn't require me to rewrite the storage once again.

At the moment all folders are stored in the config setting QuickFolders.folders , and it can take quite a chunk of storage space when you have many folders. By the way, the attribute entry.invalid is set by the function QF.Interface.updateFolders() if a valid folder cannot be returned based on its URI - for this is uses the function QF.Model.getMsgFolderFromUri(folderEntry.uri, false) .

  for (let i = 0; i < QuickFolders.Model.selectedFolders.length; i++) {
    let folderEntry = QuickFolders.Model.selectedFolders[i],
        folder, button;

    if (!this.shouldDisplayFolder(folderEntry))
      continue;

    folder = QuickFolders.Model.getMsgFolderFromUri(folderEntry.uri, false);
    countFolders++;
    if (!folder) {
      invalidCount++;
    }
    if (!minimalUpdate) {
      // restore invalid folders, too
      button = this.addFolderButton(folder, folderEntry, offset, null, null, tabStyle, isFirst);
      if (button) {
        if (!folder || typeof folder.server == "undefined")  {
          button.setAttribute("folderURI", folderEntry.uri);
          folderEntry.invalid = true; // add invalid to entry!
        }
      ...

Digging deeper my function getMsgFolderFromUr calls a built in function of Thunderbird:

MailUtils.getExistingFolder(uri, checkFolderAttributes);

So the question is whether this function may be called to early during updating Thunderbird, with the folders not being ready to parse by MailUtils - this would be unfortunate as my calling code is still largely synchronous. It would be easy to fix by the user running the "find orphaned tabs" command - which will re-evaluated all folder URIs and should reset valid tabs to its correct status:

[mintyh]

Using "find orphaned tabs" reported "0 orphans".

As per other users above, clicking on a 'broom icon' tab showed the folder correctly, and dragging an email to the "quicksort" icon (just to the left of all the folder tabs, the one with the blue arrow pointing diagonally right and up) allowed me to file that email in a tab folder.

But any attempt to drag an email over any of the 'broom icon' tabs refused to allow filing that way.

Removing the first tab immediately made the broom icons disappear from all other tabs and returned their drag/drop functionality. (I realised I didn't need that first tab anymore and didn't bother to restore it- merely removing it instantly fixed the problem.)

[RealRaven2000]

interesting that remind the first tab fixed the issue. did you by any chance back up the folders beforehand as i can have a look at the data? one tab breaking the subsequent ones is s but if a worry so if ib can i would like to get to the root cause of this.

[snafu1282]

Hi. Thank you very much for the explanation. However, I think I have to throw another monkey wrench into the works. You see, I used the "find orphaned tabs", several times in fact. It never found any orphaned folders, or at least it reported zero found. Sorry.

[RealRaven2000]

Hi. Thank you very much for the explanation. However, I think I have to throw another monkey wrench into the works. You see, I used the "find orphaned tabs", several times in fact. It never found any orphaned folders, or at least it reported zero found. Sorry.

Sure - so the obvious assumption is that something unforeseen happened with folder (tab) number 1 and the "orphaned" icon was shown falsely - and it also screwed up all folders to the right. So having the backup of the folder configuration would have been nice to check what's different with that one.

[RealRaven2000]

Hi. Thank you very much for the explanation. However, I think I have to throw another monkey wrench into the works. You see, I used the "find orphaned tabs", several times in fact. It never found any orphaned folders, or at least it reported zero found. Sorry.

Sure - so the obvious assumption is that something unforeseen happened with folder (tab) number 1 and the "orphaned" icon was shown falsely - and it also screwed up all folders to the right. So having the backup of the folder configuration would have been nice to check what's different with that one.

It seems we have it - you could do me a favor and look at the URI using the folder properties of an invalid Inbox you screenshotted above (7 days ago) - I think you can use the central tab (Current folder tab) to access this -via Mail Folder Commands / Folder Properties...:

I am interested in the exact text in the "Location" field - is it in any way different to what you had in the config file?

-for instance, the %40 is an encoded "@" character and I wonder whether QF mismatched it...

[snafu1282]

I am so sorry, but I no longer have an invalid Inbox to check. FYI, it wasn't me who took the screenshot. Also, I didn't back up the QF config because, honestly, I didn't know how, or that it could even be done. I will be backing up in future.

[mintyh]

interesting that remind the first tab fixed the issue. did you by any chance back up the folders beforehand as i can have a look at the data? one tab breaking the subsequent ones is s but if a worry so if ib can i would like to get to the root cause of this.

Apologies- like @snafu1282 , I was unaware of the backing up option, and didn't do so before removing the tab.

[snafu1282]

interesting that remind the first tab fixed the issue. did you by any chance back up the folders beforehand as i can have a look at the data? one tab breaking the subsequent ones is s but if a worry so if ib can i would like to get to the root cause of this.

Apologies- like @snafu1282 , I was unaware of the backing up option, and didn't do so before removing the tab.

Which begs a question: where is the backup option for QF? Or, @RealRaven2000, do you mean a TB feature to back up folders?

[tlhackque]

It seems we have it - you could do me a favor and look at the URI using the folder properties of an invalid Inbox you screenshotted above (7 days ago) - I think you can use the central tab (Current folder tab) to access this -via Mail Folder Commands / Folder Properties...:

I am interested in the exact text in the "Location" field - is it in any way different to what you had in the config file?

-for instance, the %40 is an encoded "@" character and I wonder whether QF mismatched it...

@RealRaven2000 :
Are you asking me, or snafu1282? Please use @tlhackque (or @snafu1282. or...) when asking questions.
I assume it's me - so here you go (I don't see any difference):

[tlhackque]

Which begs a question: where is the backup option for QF? Or
@snafu1282
I think he means options -> Licenses -> backup configuration. It may say you need a licence, but click OK and you can save the configuration - which seems OK for troubleshooting.