User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.120 Safari/537.36

Steps to reproduce:

In Thunderbird versions 68.1.2 & 68.2 go to
Options->Composition->Addressing
at "Default startup directory in the address book windows:" select an option other than "Last used directory" e.g. "All Address Books"
close Options

Actual results:

The setting is not saved, go back to Options->Composition->Addressing
at "Default startup directory in the address book windows:" the setting jumped back to "Last used directory"

Expected results:

The selected Directory should have been saved.

Confirmed.

Alice, can you please check when that broke.

Regression window:
https://hg.mozilla.org/comm-central/pushloghtml?fromchange=d33c9556acd4b06908a89c36fbe15c2e7b6398a9&tochange=87de40d001ca77e92342b9f1e6b5fc1f98fc4c45
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7e40e33da3da2640e965a153254594a234231f76&tochange=7e40e33da3da2640e965a153254594a234231f76

Thanks, Alice, record time. Our old friend, bug 1542711 which - as you may remember - also caused some LDAP chagrin.

Wow, bug 1542711 is officially my personal nightmare.
I'll take a look at this and submit a patch, thanks for reporting it.

Actually, it's a P1 since this is a regression in our release version :/

This issue is not present on trunk, so a fix I implemented in one of the many reported regressions fixed it.
Maybe is this one on bug 1560751, which will be available in 68b3?

Is this bug only present in beta 2?

Forget about the BETA questions, I'm just extremely confused.
The fact that the patch of bug 1560751 is the solution to our problem is still valid tho.

Right, the issue is not present on trunk and also not on TB 71 beta 1. Bug 1560751 was fixed in TB 68 beta 3 and is consequently also fixed in the succeeding ESR 68 series.

So something fixed the issue on trunk. Let's ask Alice again.

Alice, thanks again for finding the original regression, can you also locate where that got fixed on trunk. Many thanks in advance.

I can reproduce the issue on 68.2.0
However, I cannot reproduce on 71.0b1, Daily72.0a1(20191027074723)

There is more regression after the regression of comment#2.
Regression window in c-c 69 cycle, always "Last used directory" -> always blank

https://hg.mozilla.org/comm-central/pushloghtml?fromchange=e0cb4807daeec4bf9d7517e09623da43f1a87299&tochange=d15c56d62143a589c71354a0659e3f5488a6540b
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=38aa0201f6454456aa5f0077a050e0eb03335c8d&tochange=b23bd78e4d949c20a5e83f852958cd5fa58e02ea

And eventually fixed.
Fixed range, always blank -> The selected Directory

https://hg.mozilla.org/comm-central/pushloghtml?fromchange=f4e5910b4eedb90f56141b617c2da533cade625e&tochange=62bf2165d66e05948aed74b548f377dbc6347ce7
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8fd4efa75b558406390c316a7e4d1fc288715866&tochange=8fd4efa75b558406390c316a7e4d1fc288715866

Tried in 71.0b1, the bug seems squished there.

OK, so by the looks of it, bug 1560751 from the first regression range made it "always blank" and then re-arranging the prefs in the second range made it work again. So when testing the compose sidebar for bug 1560751 we didn't notice that it destroyed the preference.

Now it won't be much fun to figure out what part of bug 1498332 or bug 1565789 fixed the issue.

Alex, back to you. Building TB 68 locally isn't much fun, but you can just get a debug build from the Treeherder and unpack onmi.ja and then change JS files directly. Talk to me on IRC for details.

Thank you so much Alice for the detailed overview, and thanks Jorg for referencing the necessary bugs.

I'm compiling 68 locally to hunt this down.
Wish me luck!

I can't find what changed in 71 that caused this to work, but I think I found the issue from another point of view.
All the other menulists work as expected, only the defaultStartupDirList wasn't getting a value at all, even if the pref was saved correctly the value always returned empty.

This issue happens in the initAbDefaultStartupDir method, where we're trying to select the menulist item based on the saved pref.
For whatever reason, the item is not selected and the value gets emptied.

Since the menulist CE automatically selects the item based on the stored value, simply setting the correct value fixes the problem.

What do you think? Is this an acceptable fix?

But that comment is not relevant anymore since the de-xbl of the menulist.

If the stored URI is not in the list, this code in the menulist-addrbook.js takes care of it:

// Attempt to select the persisted or otherwise first directory.
      this.selectedIndex = this._directories.findIndex((d) => {
        return d && d[type] == this.value;
      });

      if (!this.selectedItem && this.menupopup.hasChildNodes()) {
        this.selectedIndex = 0;
      }

Looks like we need to hand-roll the faulty selector :-(

If the stored URI is not in the list, this code in the menulist-addrbook.js takes care of it:

Sorry, I didn't see this in time. But what happens then:
dirList.value = startupURI;

So that will then select the first entry? Which is all address books? But the intent was to select "last used" which doesn't have a URL.

I don't care, this way or the other.

(In reply to Jorg K (GMT+2) from comment #19)

Sorry, I didn't see this in time. But what happens then:
dirList.value = startupURI;

So that will then select the first entry? Which is all address books? But the intent was to select "last used" which doesn't have a URL.

It selects index 0, which for me is always "Last used directory"...isn't it?

This is Alex patch for trunk. WFM, so I have no problem using this on all branches. Magnus?

Pushed by mozilla@jorgk.com:
https://hg.mozilla.org/comm-central/rev/013567062ce3
Fix address book default startup directory in preferences panel. r=mkmelin DONTBUILD

TB 68.2.1 ESR:
https://hg.mozilla.org/releases/comm-esr68/rev/19f0f0a8ee5b9ca8a4faff084578f92ad13ff445

Working in my TB 68.2.1 build.

TB 71 beta 2:
https://hg.mozilla.org/releases/comm-beta/rev/a280ae7d00bafe5028188d736de36ee19f094178