Does this still repro in the current version? In M54 on Linux, when I middle-click the new tab button it only opens a new blank tab without trying to navigate or search.

Still repros in Linux Chrome 54 and 55 for me.

Interesting; maybe it only works on certain distros or there's some hidden option somewhere.

In any case, the relevant code appears to be here:

https://cs.chromium.org/chromium/src/chrome/browser/ui/views/tabs/tab_strip.cc?q=EF_MIDDLE_MOUSE_BUTTON+clipboard&sq=package:chromium&dr=C&l=2671

 void TabStrip::ButtonPressed( 
 ...
   controller_->CreateNewTabWithLocation(clipboard_text);

This function should probably perform the same checks we have inside  TabStrip::OnPerformDrop(const DropTargetEvent& event) such that if the content is a URL and the URL has the scheme JavaScript, we behave differently.

Having said that, the intent of removing JavaScript from paste in the URL bar is to help protect the user from a self-invoked XSS attack (https://blogs.msdn.microsoft.com/ieinternals/2011/05/19/socially-engineered-xss-attacks/). This threat doesn't really exist in this code path because the New Tab button opens a tab outside of the current document's context. This means that the JavaScript runs in the security context of "about:blank" and thus it should not have access to anything of interest.

Instead of mirroring the OnPerformDrop logic, it may make more sense to just call OmniboxView::SanitizeTextForPaste(const base::string16& text) on the string, as that's what the Omnibox itself does and this could result in functional improvements as well.

I kinda think this is WontFix, for the reason mentioned in the last paragraph of comment 4.

If we want to make the behavior uniform, I'm not strongly opposed.  We already kinda know we want to unify the omnibox paste and tabstrip drop logic, so the right way to do this in that case would probably be to go ahead and unify these some and then make sure this middle click calls into that logic.

See also the discussion thread on https://codereview.chromium.org/2322253004/ , where some of the above code was getting refactored, and I talk in more detail about possible ways to refactor this stuff.

Per #6, setting status to untriaged to let Omnibox/Tabstrip teams decide whether this is something we even want to fix.

I think https://codereview.chromium.org/2421423002/ is the simplest tactical fix, but it sounds like there's some work underway to consider a more global unification between these two areas.

pkasting@, what are you final thoughts on this?  I'd rather not keep this simple "bug" (bug in quotes because the behavior is debatable) open.

We have a simple code fix ready to be submitted.  There's also an argument for WontFix.  I'd rather not push this further waiting some refactoring.  Either decide the behavior is what we want or not and let's close it.

Let's not land a patch just to fix this.

If in the future someone lands a fix that unifies the underlying implementation more, and as part of that the easy thing to do here is to change this behavior, I'm not opposed.