1355885 - Very limited/slow functionality with Outlook/Hotmail

Status: RESOLVED WONTFIX

(Thunderbird :: Untriaged, defect)

Description

[Dave F.]

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20170323105023

Steps to reproduce:

Have been trying to access my Outlook/Hotmail account via Thunderbird 52.0. There is very limited connectivity, with the most usual response being a message that the connection timed out. Also, the IMAP folder list isn't showing all the folders any more. This issue started approximately one week ago.

The Outlook/Hotmail works perfectly if I access it through my browser (Firefox 52.0.2).


Actual results:

Here are a couple of topics concerning this issue:

http://forums.mozillazine.org/viewtopic.php?f=39&t=3028785&p=14742580#p14742580

https://support.mozilla.org/t5/Thunderbird/IMAP-Email-Incredibly-Slow/m-p/1389369

Comment 1

[Wayne Mery (:wsmwk)]

While multiple reports may be an indication of a potential bug, multiple reports alone is not enough here because outlook and hotmail have such a terrible track record of instability and reliability. Half the outlook/hotmail bugs worked in the past year have been closed invalid, and the other half (if you exclude this bug) are not confirmed bugs - https://mzl.la/2oZBcNy

Please determine whether each users reports is observable regression, where the problem exists in version X+1 but not in version X reprodicable when Windows is started safe mode.  And if so, the regression range should be determined.

Comment 2

[Wayne Mery (:wsmwk)]

It's not clear to me that we have a confirmed code defect here.

Comment 3

[IU]

If you open up Error Console and monitor it when you click a hotmail.com/outlook.com folder, you will notice you get:

05:27:15.427 uncaught exception: 2147746065 1 autosync.js:210:13

Comment 4

[Eric Moore]

IU:

I can't reproduce that error in the error console using version 52.0.1. I checked that the Outlook folder I clicked on is configured to have a offline folder. 

Wayne:

Going back to an older version doesn't seem to help. Its not a question of whether or not we have a code defect. Its started working again for me and a few others while using the same version and profile, though most still have the same problem. Its a question of whether or not we should try to do something to make Thunderbird less fragile/brittle. This problem has been going on for over 30 days. 

We appear to be sending a sequence of IMAP commands that conforms to all of the relevant rfc's that for some unknown reason doesn't work well with the outlook/hotmail/office365 servers nowadays. Microsoft insists its Thunderbird's fault (people have gone through their support channels). You're claiming its Microsoft's fault. Most non-Microsoft email clients don't have this problem. Why are we so reluctant to study what they do and do something similar, in order to support OUR users?

Comment 5

[Wayne Mery (:wsmwk)]

Please understand,  I'm not saying people don't have problems, and I'm not discouraging anyone from determining if there is a bug. I'm only saying so far there isn't a confirmed bug, because 10 people with slowness does not make a bug - there must be some root commonality - it started on date X, it happens when I do Y but not Z, it started precisely with version v.r.m, it only happens on files bigger than N, they show the same flaws in an imap log, etc.  

Someone will need to lead, and assist the users figuring this out, because I have no code skills or understanding of imap. (nor the time)  Here are some choices:

1. If something got demonstrably worse over time or at date X - it was good X weeks or months ago and now it is slow - then the user must determine if it was caused by a change in TB version, a change in other software, or something else in their environment (bad memory, more disk used, etc.)  Anyone who does support can help users with this. Start with [1]  or whatever you like. But note, if a user starts doing destructve things to their system (deleting files, running "cleaners", etc) and don't keep track of what they did then you potentialy lose them as a testcase for finding the root cause of their problem.

2. Have user get an imap log and then hope an imap expert (which are rare) comes along. (It also helps to have first proved that most of the frequent external causes of problems isn't involved [1].

Note also - multiple people having the same slowness problem is both a blessing and a curse. If the same cause is involved then solutions come more quickly than when different causes are involved, and you get competing reports of X helps for user A but not for user B - diagnosis quickly gets complicated. 

[1] https://wiki.mozilla.org/Thunderbird:Testing:Memory_Usage_Problems

Comment 6

[Wayne Mery (:wsmwk)]

(In reply to IU from comment #3)
> If you open up Error Console and monitor it when you click a
> hotmail.com/outlook.com folder, you will notice you get:
> 
> 05:27:15.427 uncaught exception: 2147746065 1 autosync.js:210:13

This is just an annoyance and can be ignored

Comment 7

[Wayne Mery (:wsmwk)]

Another stragey to quickly narrowing in on a potential bug is to focus like a lazer on just one user who preferably has all three of a) time and commitment, b) reliably reproduces the issue, c) has some smarts.  The user reporting bug 1341394 comment 7 seems to be such a person. (not ruling out those in this bug - but the guy in the other bug strongly offered)

Comment 8

[Chris]

I'll add my name to the list of users experiencing the slowness. My email is an outlook.com and my wife's is a hotmail.com, and we both have the issue. I do not have time machine so cannot accurately pinpoint a date when this started but it is about the end of March. Microsoft was reported to have made a change around that time. I also lost the ability to have TB Lightning access my outlook calendar around that time as well.

It is clear that Microsoft is the root cause. TB support now has to decide if they are prepared to investigate and provide an update, or be obstinate and say TB works fine with all other imap servers and are not changing anything. Unfortunately, I think Microsoft is too big to ignore.

Let me know if I can provide and logs or run any tests to help identify the problem.

Comment 9

[Wayne Mery (:wsmwk)]

http://forums.mozillazine.org/viewtopic.php?p=14744156#p14744156 suggests "changing my incoming server to outlook.office365.com" and down further changing smtp to smtp.office365.com

Does that help?

Comment 10

[Chris]

This change has been working for me over the last few days.

Comment 11

[Eric Moore]

Changing the server seems to help. Enough that I updated http://kb.mozillazine.org/Hotmail to recommend it if you run into performance problems. Unfortunately many of the people who complained about this problem haven't mentioned whether that workaround works for them or not so I suggest waiting another week before closing this bug report. 

It is not clear why Thunderbird, but not email clients such as "em client" were effected. Nor is it clear why for long periods some Thunderbird users were effected, but not others.

Comment 12

[Dave F.]

I am the original submitter of this bug. A few days ago, I revised server info in Thunderbird to reflect Comment #9 above, by changing my incoming server to outlook.office365.com and down further changing smtp to smtp.office365.com.

I am pleased to report that Thunderbird is back to full speed and functionality! Thankfully this was an easy fix. Puzzling that it took so long for someone to come up with this solution. Anyway, many thanks to all. Great work!

Sign me, a devoted Mozilla fan..................

Comment 13

[Eric Moore]

I think there has been enough feedback in the MozillaZine thread to confirm that this problem has a reliable workaround. I'll change the status to "wontfix" since there is no "notourbug" and "invalid" implies there was something wrong with the bug report.

Comment 14

[mmortal03]

(In reply to Eric Moore from comment #13)
> I think there has been enough feedback in the MozillaZine thread to confirm
> that this problem has a reliable workaround. I'll change the status to
> "wontfix" since there is no "notourbug" and "invalid" implies there was
> something wrong with the bug report.

Well, technically, it could still be that it's a bug in how Thunderbird handles whatever that previous Microsoft server was throwing at it, but it could also be that Microsoft was severely throttling the previous server for whatever reason, or that there was a bug on Microsoft's end. I guess we'll never know.