With Thunderbird 19.0b1 we have this new regression which pops-up the LDAP authentication dialog again and again for each lookup. Thunderbird no longer retrieves the password from the password manager. Also when you remove the password you will no longer be able to save it again, the checkbox is simply not present anymore. This should block version 19.0.

Also see: https://getsatisfaction.com/mozilla_messaging/topics/thunderbird_19_doesnt_offer_to_save_ldap_password

I too am seeing this issue, on Mac OSX 10.6.8

Would someone be available to check for the regression range? A documentation which covers those steps can be found here: https://quality.mozilla.org/docs/bugzilla/guide-to-triaging-bugs-for-firefox/finding-a-regression-window/ Thanks!

This is basically a different instance of the bustage seen in bug 801916 that was caused by bug 723004. I think I started a WIP patch for this, but ran into some issues. I'll try and dig it out again soon.

This would also have to block Thunderbird 19.0.

Thunderbird isn't following the rapid release now, as per the recently revised governance system. SeaMonkey might want it though.

Not sure if this affects SeaMonkey or not, but I'm unlikely to complete a reviewed patch before the release builds happen for the next SM release. I can probably advise for potential solutions if necessary.

From the above comments I can't make out. Can someone summarize by which Thunderbird/Earlybird release we are going to see this bug fixed?

I hope this gets fixed soon. This bug is extremely annoying: Try typing an email address in the To: field and find that after every two characters, TB pops up the password window because it tries to query the LDAP server.

I can confirm this affects SeaMonkey User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16 Build identifier: 20130217195808

I can confirm that this affects both Windows and Linux versions of Seamonkey 2.16: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16 Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16 Definitely annoying if you have addressing set up to query LDAP.

Also affecting Seamonkey 2.16 on OS X: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16

Hi folks, there's no need to comment about which versions this is affecting, this bug is still marked as "new" so it is still a bug. As I mentioned in comment 8, I've not been able to do fix this yet due to other commitments, I expect I may be able to in the next couple of weeks, however, anyone is welcome to take the bug and fix it. Please do not comment unless you are actually providing a fix - we know it is an issue and appropriate tracking flags are set.

For those which are annoying that that bug is after two months and two next Seamonkey releases (2.16.1 and 2.16.2) still here - Linux users can switch to Claws mail, where LDAP support is fine (including possibility to write to LDAP addressbook and ability to have more than two mail addresses per contact, among other things).

(In reply to Franta Hanzlik from comment #18) > For those which are annoying that that bug is after two months and two next > Seamonkey releases (2.16.1 and 2.16.2) still here - Linux users can switch > to Claws mail, where LDAP support is fine (including possibility to write to > LDAP addressbook and ability to have more than two mail addresses per > contact, among other things). or WIN-User can switch to the official release of TB (AFIAK v 17.0.4) where this problem still doesn't exist. ;-) As I found out is that this strange behavior also dosen't exist in SM 2.15.2

Neil, I could do with some ideas here... The issue is that nsLoginManagerPrompter now requires a window so that if we're in private browsing mode can be detected or not, however: 1) Autocomplete interfaces don't give us any information about the window we're in. 2) The current code seems to try and get the address book window, but having the address book window open doesn't actually work as a workaround (http://hg.mozilla.org/comm-central/annotate/323851e9e786/mailnews/addrbook/src/nsAbLDAPListenerBase.cpp#l163) 3) I'm not convinced changing to a channel would work (even if it was easy) as we'd still not have a window to pass along.

Neil, what do you think about this? It changes the code to use the most recent window (i.e. topmost) and so therefore we'll always have a window to check for private browsing or not. It could lead to the dialog popping up in a different window if the user is quick at switching, but I don't think that's going to be a big issue.

Comment on attachment 734513 [details] [diff] [review] Possible fix Well, without a password-protected LDAP server (not AD, because that seems to authenticates transparently over GSSAPI) I can't verify this, but it seems reasonable. GetWindowByName is looking for a window which was opened using the second parameter to window.openDialog, but I don't think we ever did that. Perhaps something used to use the document element ID as the name, but my CVS archaeology isn't up to that. Anyway, the autocomplete timeout is quite small (0.3s) so I doubt it will be a problem. >@@ -157,17 +158,28 @@ NS_IMETHODIMP nsAbLDAPListenerBase::OnLD > return rv; > } I assume this is the end of the block that gets the window watcher service. I would prefer this to be moved to just before its use. Another alternative would be to do something like nsCOMPtr<nsIWebNavigation> webNav(do_GetInterface(window)); nsCOMPtr<nsIAuthPrompt> authPrompter(do_GetInterface(webNav));

Updated for comments. I've pushed it to try and I'm looking for some folks to test the builds on an authed LDAP server: https://tbpl.mozilla.org/?tree=Thunderbird-Try&rev=53750993d605 Should be up in an hour or so.

To test: - create an LDAP address book for a server that requires auth - Compose an email, start addressing, check that you get a dialog box asking for the password, and that you can save the password - Compose a second email, check password prompt doesn't appear - Remove the stored password and restart TB - Repeat the compose steps but using the Address book quick search in the AB window.

Comment on attachment 735061 [details] [diff] [review] The fix v2 Works nicely for me :-)

Comment on attachment 735061 [details] [diff] [review] The fix v2 [Triage Comment] Given the current trunk situation, I pushed this directly to beta so that we could get some testing on it. Will leave open and tracking to ensure we fix it on Nightly and Aurora.

https://hg.mozilla.org/comm-central/rev/d47c6eecf7eb https://hg.mozilla.org/releases/comm-aurora/rev/19d808bd643a