Thunderbird/Thunderbird15.0SupportIssues: Difference between revisions

Thunderbird/Thunderbird15.0SupportIssues (view source)

Revision as of 19:35, 5 October 2012

1,201 bytes added , 5 October 2012

→‎Not so minor

Rtanglao

Confirmed users

5,365

edits

@@ Line 24: / Line 24: @@
 ##* Error: NS_ERROR_XPC_JS_THREW_JS_OBJECT: 'TypeError: match[1] is undefined' when calling method [prplIAccount::connect] Source File: resource:///components/imAccounts.js Line: 620
 ## People using XMPP servers that really require DNS SRV support which is {{bug|14328}} (a long standing platform bug!) - these servers are rare but they do exist; no workaround until bug 14328 is fixed!
-## People attempting to connect to jabber.org - NOT A THUNDERBIRD bug, appears that the jabber.org server is under a DDOS attack
+## People attempting to connect to jabber.org - '''NOT A THUNDERBIRD bug''', appears that the jabber.org server is under a DDOS attack
-## Some people getting disconnected from Google Talk after a successful authentication, downloading the contact list, and sending their vCard, {{bug|775977}}
+## Some people getting disconnected from Google Talk after a successful authentication, downloading the contact list, and sending their vCard, {{bug|775977}} - '''NOT A THUNDERBIRD BUG!''' - update from Florian 5Oct2012: "We finally identified the cause of the issue. This happens for users who have one contact who has iTeleport (http://iteleportmobile.com/) installed. This broken piece of software broadcasts invalid XML (that's a bug on iTeleport's side) and the Google Talk servers relay it (that's a serious bug on Google's side; I emailed Google to see if we can get google to discuss this bug. The behavior of Thunderbird in this case (closing the connection) is what the XMPP specification says we should do. I know some other clients are able to ignore the invalid XML and continue parsing the following data. Up to now my attempts to convince the Mozilla XML parser to resume parsing after receiving such junk have failed."
-## Twitter sometimes stops sending us new tweets in the stream, {{bug|786404}} - not reproducible - WORKAROUND - go offline and then back online
+## Twitter sometimes stops sending us new tweets in the stream, {{bug|786404}} - seems to be reproducible if you put the machine to sleep - WORKAROUND - go offline and then back online
 ## <del>OpenFire server doesn't follow XMPP standard for digest-MD5 authentication - it's a popular server so Florian is coding a workaround for a future release in {{bug|787046}} - (assuming OpenFire doesn't fix it quickly) - '''WORKAROUND''': get server administrator to disable the DIGEST-MD5 authentication method in OpenFire's configuration</del> - '''fixed in TB15.0.1'''
 # IM Feature requests:
-##support for AIM, MSN, Yahoo (libpurple add-on could fix this or {{bug|761986}} for MSN only)
+## <del>support for AIM, MSN, Yahoo (libpurple add-on could fix this or {{bug|761986}} for MSN only)</del> - Fixed with an add-on for TB15,16 and 17: From Florian "A binary add-on offering support for more chat protocols has been released:
+https://addons.mozilla.org/en-US/thunderbird/addon/additional-chat-protocols/ This add-on adds support for the AIM, Bonjour, Gadu-Gadu, GroupWise,ICQ, MSN, MySpaceIM, Netsoul, SIMPLE, Sametime and Yahoo! instantmessaging protocols."
 ##distinct audio and visual notifications [http://gsfn.us/t/33gdg GS],
 ## [http://en.wikipedia.org/wiki/Off-the-Record_Messaging off the record support] {{bug|788153}}