Links don't open in new tab in Chrome in Bug Reports

ID:105955
 
Dec 19 2010, 11:06 pm
BYOND Version:N/A (Website Bug)
Operating System:Windows 7 Ultimate 64-bit
Web Browser:Chrome 8.0.552.224
Applies to:Website
Status: Deferred
This issue may be low priority or very difficult to fix, and has been put on the back burner for the time being.
Descriptive Problem Summary:
Middle clicking on links in a forum post or blog post open in the current tab in Chrome on Windows 7.

Numbered Steps to Reproduce Problem:
View a forum post (e.g. http://www.byond.com/developer/forum/?id=768653) in Chrome and middle click on a link (either "Games Page" or "Developers Page" in the one linked).

Expected Results:
Link should open in a new tab.

Actual Results:
Link opens in current tab.



Workarounds:
Right click->open in new tab



I can't reproduce in Firefox. I don't know why this happens, but it is super annoying. I have not seen this behavior on any other website (and most links on this website work, too- e.g. the menu links).
#1 Dec 20 2010, 12:50 am
I'm using the exact same version of Chrome and did some poking around. Was only able to reproduce this problem with off-site links such as hosted images and member homepages (not BYOND community pages).

Went to some other sites and confirmed this is not the normal behavior for Chrome, normally middle mouse will open a new tab regardless of if the link is for the same domain or not.
#2 Dec 20 2010, 7:21 am
Chrome bugs need to be reported to Google, not to us. Style issues are one thing, but we can't predict how windows are supposed to behave with Chrome's click behavior; as long as the anchor tags are correctly formatted, it's up to Chrome to get that right.
#3 Dec 20 2010, 10:48 am (Edited on Dec 20 2010, 11:19 am)
The bug only occurs on your website and only in specific cases. I'll try to look into it more.

Bug report filed with Chromium:
http://code.google.com/p/chromium/issues/detail?id=67592
#4 Dec 20 2010, 11:20 am
The links you put in your test post are both properly formatted, and neither has a target attribute. The only difference between them is that one is a relative URI and the other is not.

The only plausible case for this being a website bug as opposed to a Chrome bug would be if the relative URI was the one that didn't open in a new tab as intended. In that case then there could perhaps be some kind of issue with URLs on this site causing the incorrect behavior. That would be a big stretch though; a Chrome bug is still more likely. But since it's a URL to another site causing the incorrect behavior, all doubt is removed. Chrome is clearly to blame for the inconsistency. This was always the most likely explanation anyway since AFAIK there's no way in regular HTML to control tab behavior in browsers; all of that is done internally by the browser logic itself.
#5 Dec 20 2010, 11:42 am
I believe it's a problem on your end- well, sort of.

Your footprint live script (http://script.footprintlive.com/?site=www.byond.com) has a function ot_f which is handling clicks. If I disable the script, I can middle click fine.
#6 Dec 20 2010, 11:52 am
Ah, interesting. That script hadn't even occurred to me because I didn't think it had anything to do with clicks.

I've reopened the report.
#7 Dec 20 2010, 11:57 am
I'm told by the Chromium developers that this has to do with the click handlers- in Chrome, click handlers work for more than just left click, whereas other browsers only run them for left click. This causes chrome to interpret the click handler when middle clicking, which messes things up. They said that this should be fixed in a future version of Chrome (by limiting the functionality of click handlers strictly to left click).

I suppose it's arguable who the bug is on: Chrome for providing additionally functionality for click handlers or that script for doing the actual screwing up (you'd think they would test that stuff!). I don't know if there's anything you can do on your end, for now I'll deal with it until the fix is released for Chrome.

#8 Dec 20 2010, 12:16 pm
Yeah, you make a good point there. It's foolish of Google to add functionality to a handler in a way that could screw up existing code, but it's equally foolish that the functionality isn't expected to be there in the first place.