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.
Assignee: nobody → rsx11m.pub
Status: NEW → ASSIGNED
Summary: Context menu shows "Report Email Scam" despite this function isn't yet available → Context menu shows "Report Email Scam" despite this function not yet available
(I think I've got the grammar in the summary right now, sorry for the noise...)
Summary: Context menu shows "Report Email Scam" despite this function not yet available → Context menu shows "Report Email Scam" despite this function not being available yet
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 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.
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → INVALID
> (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.
You need to log in before you can comment on or make changes to this bug.