Current behaviour in trunk (and 2.0.x) is for the "Report Web Forgery..." menu action to launch google's report page in a new tab. This seems unsafe, since it leaves the phish site open, loaded, and (presumably, since they are currently reporting it) not marked as a phish site. This leaves open the possibility that the user, or another user of the same computer, might come back later and, being less vigilant this time, mistake the scam site for their actual bank/paypal/ebay login. The menu item should load in the existing tab. We probably don't need to destroy history, indeed it would likely be annoying to do so, but we should at least get the scam site off the screen. Note: the opposite menu item, "This site is not a forgery" can continue to open in a new tab since, in that case, it is quite plausible that you want to continue interacting with the site. Will attach 1-liner patch below

Would it be better if we also handled standard modifiers (ctrl or middle mouse for new tab, shift for new window)?

(In reply to comment #2) > Would it be better if we also handled standard modifiers (ctrl or middle mouse > for new tab, shift for new window)? I don't know if we really want to help people keep the site open, but more broadly from a behavioural point of view, I don't know the precedent here. Items in the bookmarks menu, for instance, don't respect modifier keys (as tested on 2.0.0.2 Mac) nor did the old Report Web Forgery item. I'm not sure I see a convincing reason to start doing that here.

When I middle click a bookmark, it opens in a new tab. There appears to be code for this: http://lxr.mozilla.org/seamonkey/source/browser/base/content/browser-menubar.inc#420 I get this behavior on menu items that load web content (e.g., history items do the same thing, so does "release notes" in the help menu). I think openUILink in browser.js will give the desired behavior. I don't have a strong opinion about this so I'll let someone else decide.

Per Tony's comment. mconnor - please be mean, it's a tiny patch, might as well get it right.

Comment on attachment 257718 [details] [diff] [review] Patch to use openUILink instead r=me, I sadly don't have anything mean to say here try something bigger, I'm sure I'll find something.

mozilla/browser/components/safebrowsing/content/report-phishing-overlay.xul 1.5

We need to pass the event into openUILink or it won't know about modifiers.

Comment on attachment 257748 [details] [diff] [review] pass the event into openUILink Shoot. Makes sense to me. mconnor?

Comment on attachment 257748 [details] [diff] [review] pass the event into openUILink Indeed, we should have caught this. I blame too many Macs. I'll land this shortly.

mozilla/browser/components/safebrowsing/content/report-phishing-overlay.xul 1.6