Last Comment Bug 833971 - LDAP password requested for each lookup even if password is saved (also can't save it again after removal)
: LDAP password requested for each lookup even if password is saved (also can't...
Status: RESOLVED FIXED
[regression:TB19][gs]
: regression
Product: MailNews Core
Classification: Components
Component: LDAP Integration (show other bugs)
: 19
: All All
: -- major with 8 votes (vote)
: Thunderbird 23.0
Assigned To: Mark Banner (:standard8)
:
Mentors:
https://getsatisfaction.com/mozilla_m...
: 708223 816468 834258 837804 849125 853553 (view as bug list)
Depends on: 801916
Blocks: 723004
  Show dependency treegraph
 
Reported: 2013-01-23 13:48 PST by Henrik Skupin (:whimboo)
Modified: 2016-06-18 01:01 PDT (History)
34 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
-
+
+
fixed
+
fixed
?
?
?


Attachments
Possible fix (2.10 KB, patch)
2013-04-08 01:39 PDT, Mark Banner (:standard8)
no flags Details | Diff | Splinter Review
The fix v2 (2.49 KB, patch)
2013-04-09 02:03 PDT, Mark Banner (:standard8)
neil: review+
ludovic: feedback+
standard8: approval‑comm‑beta+
Details | Diff | Splinter Review

Description Henrik Skupin (:whimboo) 2013-01-23 13:48:40 PST
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.
Comment 2 Henrik Skupin (:whimboo) 2013-01-24 09:54:48 PST
*** Bug 834258 has been marked as a duplicate of this bug. ***
Comment 3 marc 2013-01-24 13:07:19 PST
I too am seeing this issue, on Mac OSX 10.6.8
Comment 4 Henrik Skupin (:whimboo) 2013-01-24 23:21:51 PST
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!
Comment 5 Mark Banner (:standard8) 2013-01-25 00:43:06 PST
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.
Comment 6 Henrik Skupin (:whimboo) 2013-01-25 01:04:08 PST
This would also have to block Thunderbird 19.0.
Comment 7 Mark Banner (:standard8) 2013-01-25 01:37:07 PST
Thunderbird isn't following the rapid release now, as per the recently revised governance system.

SeaMonkey might want it though.
Comment 8 Mark Banner (:standard8) 2013-02-04 12:17:08 PST
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.
Comment 9 Shobhit Gupta 2013-02-07 10:02:10 PST
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?
Comment 10 Christoph Fischer 2013-02-19 03:05:17 PST
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.
Comment 11 Andreas Wagner [:TheOne] 2013-02-21 02:01:25 PST
*** Bug 837804 has been marked as a duplicate of this bug. ***
Comment 12 Andreas Wagner [:TheOne] 2013-02-21 02:02:51 PST
*** Bug 708223 has been marked as a duplicate of this bug. ***
Comment 13 Dash 2013-02-23 06:58:28 PST
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
Comment 14 worldoff9908 2013-02-26 12:36:58 PST
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.
Comment 15 I.R. 2013-02-27 07:53:09 PST
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
Comment 16 Mark Banner (:standard8) 2013-02-27 12:35:46 PST
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.
Comment 17 rsx11m 2013-03-08 10:49:55 PST
*** Bug 849125 has been marked as a duplicate of this bug. ***
Comment 18 Franta Hanzlik 2013-03-21 02:02:56 PDT
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).
Comment 19 Mexx 2013-03-21 03:31:28 PDT
(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
Comment 20 Phoenix 2013-03-22 02:34:43 PDT
*** Bug 853553 has been marked as a duplicate of this bug. ***
Comment 21 Mark Banner (:standard8) 2013-03-25 10:04:18 PDT
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.
Comment 22 Mark Banner (:standard8) 2013-04-08 01:39:03 PDT
Created attachment 734513 [details] [diff] [review]
Possible fix

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 23 neil@parkwaycc.co.uk 2013-04-08 03:04:56 PDT
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));
Comment 24 Mark Banner (:standard8) 2013-04-09 02:03:23 PDT
Created attachment 735061 [details] [diff] [review]
The fix v2

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.
Comment 25 Mark Banner (:standard8) 2013-04-09 02:05:32 PDT
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 26 Ludovic Hirlimann [:Usul] 2013-04-09 04:11:57 PDT
Comment on attachment 735061 [details] [diff] [review]
The fix v2

Works nicely for me :-)
Comment 27 Ludovic Hirlimann [:Usul] 2013-04-09 08:58:25 PDT
*** Bug 816468 has been marked as a duplicate of this bug. ***
Comment 28 Mark Banner (:standard8) 2013-04-09 12:48:41 PDT
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.
Comment 29 Mark Banner (:standard8) 2013-04-09 12:49:08 PDT
https://hg.mozilla.org/releases/comm-beta/rev/d5ea73d10f3a

Note You need to log in before you can comment on or make changes to this bug.