653798 - Context menu shows "Report Email Scam" despite this function not being available yet

Status: RESOLVED INVALID

(Thunderbird :: Message Reader UI, defect)

Description

[rsx11m]

As was pointed out in bug 623198 comment #17, the scam feature is not yet completed and specifically doesn't have a black/white-list provider in place. Consequently, bug 368635 and bug 370181 commented out the respective parts.

However, as an apparent residual of that implementation, right-clicking on a link in a message provides a "Report Email Scam" which doesn't perform any function. Thus, it should be hidden similar to the other UI elements related to the scam feature until it actually communicates with a provider.

Comment 1

[rsx11m]

Attachment: Quick fix

This patch hides the redundant context-menu item in all cases, similar to the approaches (commenting out, always collapsing, etc.) for the other UI elements related to the reporting feature.

Ideally, these elements would be hidden if no phishing URL is found, otherwise presented to the user, but I don't think I'll work that one out. It should be kept track though of all the XUL elements and JavaScript code that will need to be reactivated or completed once a provider becomes available.

Comment 2

[rsx11m]

(I think I've got the grammar in the summary right now, sorry for the noise...)

Comment 3

[Mark Banner (:standard8)]

(In reply to comment #1)
> Ideally, these elements would be hidden if no phishing URL is found, otherwise
> presented to the user, but I don't think I'll work that one out. It should be
> kept track though of all the XUL elements and JavaScript code that will need to
> be reactivated or completed once a provider becomes available.

I think you've missed the point of the report action. I should be able to report *any* url as a suspected scam even if the scam processing doesn't think it is a scam.

I'm also not really sure that we need to remove this element for now. Reporting a scam url doesn't hurt IMO - and it does at least report it to Google, so that it can be investigated and maybe blocked from browsers accessing it.

Comment 4

[rsx11m]

Maybe I'm mistaken, but I thought that feature would rely on a phishing provider like the scam detection? If that's a different path independent from the feature detecting a scam, of course it would be the intended behavior and I agree that it should be retained. I was under the assumption that this menu action wouldn't do anything until the scam detection is hooked up with such a provider to use that list for identifying scam.

Comment 5

[rsx11m]

Comment on attachment 529161 [details] [diff] [review]
Quick fix

Ok, guess I screwed that one up. Looking at the browser.safebrowsing.provider preferences, Thunderbird/Miramar has indeed reportPhishURL set (which matches its Firefox variant) and connects to a phish-report.mozilla.com URL, whereas the keyURL and lookupURL prefs are empty in Thunderbird but refer to Google in Firefox. Thus, reporting should work but not any lookup for flagging scams.

I'm canceling the review request as the useless UI isn't useless after all, let's see if we can do anything else here in terms of basing visibility of those items on the actual presence of such URLs rather than by commenting the respective code out, so I'll keep this bug open a little longer.

Comment 6

[rsx11m]

After some discussion with Blake it becomes apparent that more would have to
be done than just commenting back in the UI parts which are currently hidden. Specifically, some integration of a black/white-list mechanism into the current scam detection would be necessary, and UI elements like "reportPhishingError" in mailWindowOverlay.xul currently aren't wired given that it may be unclear which links are supposed to be reported as false positives to the provider.

As for this bug, I'll go ahead and close it as INVALID given that the context menu has the intended behavior and I had filed the bug based on assumptions which aren't accurate. Blake didn't feel that basing UI visibility on the presence of a valid URL in those preferences would be worth the effort, and since further integration work needs to be done once a provider has been secured, reactivation can be taken care of in one of the bugs working towards that specific integration effort. It may be useful though to create a meta bug tracking the scam-feature related short- and long-term activities.

Comment 7

[rsx11m]

> (In reply to comment #6) It may be useful though to create a meta bug
> tracking the scam-feature related short- and long-term activities.

Done, see bug 654502.