1354912 - Block McAfee Anti-Spam Thunderbird Extension v2.0 for Thunderbird >= 52.0

Status: RESOLVED FIXED

(Toolkit :: Blocklist Policy Requests, defect)

Description

[Wayne Mery (:wsmwk)]

+++ This bug was initially created as a clone of Bug #1286368 +++

Please change the block requested in bug 1286368 to cover ALL versions of Thunderbird

Thanks

Extension name: McAfee Anti-Spam Thunderbird Extension
Extension UUID: {[e-mail]}
Extension versions to block: <= 2.0
Applications, versions, and platforms affected: Thunderbird *
Block severity: soft

Reasons: addon causes topcrash bug 1281610 for Thunderbird 52.0 (anticipate newer versions of 52.x will also crash). This #1 crash is at a rate 10x the #2 ranked crash. See  https://crash-stats.mozilla.com/topcrashers/?product=Thunderbird&version=52.0&days=3

(So far no resolution from McAfee)

Comment 1

[Andreas Wagner [:TheOne] [use NI]]

Does this also cause crashes for Tb versions < 52.0?
If not, why not just block it for >= 52.0?

Comment 2

[Wayne Mery (:wsmwk)]

good questions

(In reply to Andreas Wagner [:TheOne] [use NI] from comment #1)
> Does this also cause crashes for Tb versions < 52.0?

It does, yes. Just not quite such an extreme rate as it is for >= 52.0. A few examples.

bp-ed727861-bcab-42d4-a9e9-320222170129  "I don't kmow what happened. I did put McAfee on last night. I can't get into my e-mail"   shutdownhang | MsgWaitForMultipleObjectsEx | CCliModalLoop::BlockFn 

bp-0fddccfa-5fed-46df-bef6-ccbb22170308  "Upon trying to log on to McAfee Central that requested my email address, when I opened Thunderbird it appeared but was not functioning."  shutdownhang | MsgWaitForMultipleObjectsEx | CCliModalLoop::BlockFn -- #73 crash for TB45.8.0 and the vast majority involve McAfee

bp-90357083-45b9-424a-ac65-cb9622170307  "problème suite à l'installation de l'Anti-spam de McAfee"

bp-7f2c17c6-2e65-4683-8e7f-85b5c2170330  "using mcafee quickclean" shutdownhang | _PR_MD_WAIT_CV | _PR_WaitCondVar | mozilla::CondVar::Wait | nsEventQueue::GetEvent | nsThread::ProcessNextEvent | NS_ProcessNextEvent | nsThread::Shutdown | nsThreadManager::Shutdown -- however, the vast majority of crashes with this signature do not involve McAfee

That said, I don't have solid evidence in hand that this is a top crash for < 52.0


> If not, why not just block it for >= 52.0?

I definitely need this, so let's go with it.

Comment 3

[Andreas Wagner [:TheOne] [use NI]]

The block has been staged. Jorge, can you please review and push it live?

Comment 4

[Jorge Villalobos [:jorgev] (he/him)]

The block is now live.

Comment 5

[Eric Svalland]

Not happy that my A/V scanner was flat out blocked with not even an option to enable it. Is this the new model on how to treat customers? Please, stop treating customers like children and let us choose if we want to enable or disable manually like you have with Java products. I have had no issues to date with McAfee and Thunderbird.

v/r,
 Eric

Comment 6

[Wayne Mery (:wsmwk)]

For anyone inconvenienced by having the addon disabled we are sorry, but you would not want to be one of the many Thunderbird users that is impacted by constant crashing caused by the addon. 

The number of users crashing is not trivial, the crash occurs at startup so users don't have an opportunity to disable the addon (and are thus dead unless they know to start in safe mode) and McAfee has not shipped a solution.  So it came neccessary to block the addon, and perhaps should have been done months ago.  The soft block didn't seem sufficiently effective for reasons we don't understand, perhaps related to how McAfee (force?) enables the addon, so a hard block was initiated via bug 1359469.

Bottom line is McAfee need to deliver a solution to you. In the course of researching bug 1281610 I contacted McAfee in November last year to facilitate solving the issue. It is still broken. Good news is as of last week the seem to have made progress. When they shipping a solution is unknown.