Status

RESOLVED DUPLICATE of bug 474277
10 years ago
10 years ago

People

(Reporter: asrail, Assigned: standard8)

Tracking

({regression})

Trunk
Thunderbird 3.0b2
x86
Linux
regression
Bug Flags:
blocking-thunderbird3 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

10 years ago
None of my IMAP accounts is even showing the login dialog.
Both accounts using SSL and not using SSL.

One example is GMAIL IMAP:
server - imap.gmail.com

using SSL, default SSL port.

I've tested with the bugmail address, on a new profile and clicking on the account shows the following messages - sometimes more than once:
 - Invalid credentials (Failure)
 - Login to server imap.gmail.com failed


and the following warnings are raised on console (debug build):
imap://asrail@imap.google.com ... skipping, already opened
WARNING: NS_ENSURE_TRUE(*aServer) failed: file /home/asrail/mozbuilds/hg.mozilla.org/comm-central/mailnews/imap/src/nsImapService.cpp, line 2528
WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005: file /home/asrail/mozbuilds/hg.mozilla.org/comm-central/mailnews/imap/src/nsImapService.cpp, line 2569
************************************************************
* Call to xpconnect wrapped JSObject produced this error:  *
[Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIIOService.newURI]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: file:///home/asrail/mozbuilds/suiterunner/components/nsLoginManagerPrompter.js :: anonymous :: line 426"  data: no]
************************************************************
WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005: file /home/asrail/mozbuilds/hg.mozilla.org/comm-central/mailnews/base/util/nsMsgIncomingServer.cpp, line 818

Comment 1

10 years ago
Same reported for Thunderbird in bug 474003. If those are indeed identical, maybe dupe that one (currently still unconfirmed) against this one here and make it a Core/Networking bug.
(Assignee)

Updated

10 years ago
Component: MailNews: Backend → Backend
Product: SeaMonkey → MailNews Core
QA Contact: mailnews-backend → backend
Target Milestone: --- → Thunderbird 3.0b2
(Assignee)

Updated

10 years ago
Assignee: nobody → bugzilla
Flags: blocking-thunderbird3+
(Assignee)

Updated

10 years ago
Duplicate of this bug: 474003
(Assignee)

Comment 3

10 years ago
Asrail, could you try some debugging for me?

In nsImapService::NewURI, right at the start of the function, add the line:

printf("URI Spec is: %s\n", nsCString(aSpec).get());

I'd be very interested to see what that is at the point of failure.

It would then also be worth seeing if you can tie that up with any of your folder locations (e.g. right click on folder, general tab, Location field).

Updated

10 years ago
Keywords: regression
(Assignee)

Comment 4

10 years ago
The other (simpler) alternative may be a protocol log for imap: https://wiki.mozilla.org/MailNews:Logging - I'm not sure it will contain all the information, but it may help.
FWIW, GMail imap works for me.
(Reporter)

Comment 6

10 years ago
Created attachment 357504 [details]
IMAP log

Shows: URI Spec is: imap://asrail@imap.gmail.com

for both working and not working revisions.

Until now I could track down to this line:
http://mxr.mozilla.org/comm-central/source/mailnews/imap/src/nsImapService.cpp#2506
  rv = accountManager->FindServerByURI(mailnewsUrl, PR_FALSE, aServer);

it works before `changeset 30c7a484a3ae "Bug 433316 Implement backend changes for MailNews transfer from wallet to login manager. r=Neil,sr=bienvenu"'.
On current tip, *aServer stay null after this.

On http://mxr.mozilla.org/comm-central/source/mailnews/base/src/nsMsgAccountManager.cpp#1696
the last time it's called before the error happen, username is "".

On the older revision, it's:
username: asrail, hostname imap.google.com, type imap.

Top of stack trace:
#0  nsMsgAccountManager::FindServerByURI (this=0x7f5ce5df9990, aURI=0x7f5ce1946560, aRealFlag=0, 
    aResult=0x7fff03e9eb70)
    at /home/asrail/mozbuilds/hg.mozilla.org/comm-central/mailnews/base/src/nsMsgAccountManager.cpp:1696
#1  0x00007f5cee814d73 in nsImapService::GetServerFromUrl (this=<value optimized out>, aImapUrl=0x7f5ce3d58200, 
    aServer=0x7fff03e9eb70)
    at /home/asrail/mozbuilds/hg.mozilla.org/comm-central/mailnews/imap/src/nsImapService.cpp:2522
#2  0x00007f5cee81667e in nsImapService::NewURI (this=0x7f5ce4c8fce0, aSpec=<value optimized out>, 
    aOriginCharset=<value optimized out>, aBaseURI=<value optimized out>, aRetVal=0x7fff03e9f018)
    at /home/asrail/mozbuilds/hg.mozilla.org/comm-central/mailnews/imap/src/nsImapService.cpp:2568
#3  0x00007f5ced66eee8 in nsIOService::NewURI (this=0x7f5cf3453b80, aSpec=@0x7f5cdf54a160, aCharset=0x0, 
    aBaseURI=0x0, result=0x7fff03e9f018)
    at /home/asrail/mozbuilds/hg.mozilla.org/comm-central/mozilla/netwerk/base/src/nsIOService.cpp:501

Venkman is quite broken on 1.9.1, so it's hard to debug, but by the JS errors, it looks like this wrong call starts at:
http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/components/passwordmgr/src/nsLoginManagerPrompter.js#426

Attaching the log. The server configuration looks OK. This is on the new profile, without saving passwords. The password is not even asked for me.
(Assignee)

Comment 7

10 years ago
(In reply to comment #6)
> Created an attachment (id=357504) [details]
> IMAP log
> 
> Shows: URI Spec is: imap://asrail@imap.gmail.com
> 
> for both working and not working revisions.

Is that all the time? because...

> On
> http://mxr.mozilla.org/comm-central/source/mailnews/base/src/nsMsgAccountManager.cpp#1696
> the last time it's called before the error happen, username is "".

...this would imply the URL is imap://imap.gmail.com in this case, or the url processing isn't separating out the username correctly which I doubt.
(Reporter)

Comment 8

10 years ago
That's always the correct one. I've noticed that the caller was at:
/home/asrail/mozbuilds/hg.mozilla.org/comm-central/mailnews/imap/src/nsImapService.cpp:2522

which is not called when the server was found and is a specific case, anyway.

For that reason that was the last call before the errors and warnings being raised, but the server should have been found before.
(Assignee)

Comment 9

10 years ago
I've just pushed a patch for bug 474277 that *may* help this. I very much doubt it will fix this, but its probably worth checking.
(Reporter)

Comment 10

10 years ago
This patch fixes the bug.

Before trying this patch I'd noticed that the issue was with the hostnames. For instance, "imap.google.com" and "imap.gmail.com".

I'm resolving as duplicate of the newer bug, because this symptom was caused by that one.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 474277
You need to log in before you can comment on or make changes to this bug.