Page MenuHomePhabricator

Links to classes or interfaces sometimes are opened in new windows but sometimes in new tabs. This behavior should be consistent
Closed, WontfixPublic

Description

Why when I on highlighted class in phabricator code browser it sometimes opens this class in new tab and sometimes in new window. Why we have such inconsistent behavior? I'd prefer it to always open new tab instead of new window

Event Timeline

victor.passichenko raised the priority of this task from to Wishlist.
victor.passichenko updated the task description. (Show Details)

Which browser are you using? I can't reproduce this.

Chrome

For example this file:
https://phabricator.fb.com/diffusion/E/browse/tfb/trunk/www/flib/core/datatype/VersionedMemcacheDataType.php$19
when I click on CoreDataType it opens new tab
but when I click on MemcacheDataType it opens new window

I haven't had access to phabricator.fb.com since April 2011, but let me see if I can reproduce here...

I sort of managed to reproduce this, but it's not very consistent. I was able to get one new window in about 50 clicks. I think this is an event handling issue, not an issue with which link you click (I can very rarely get the popup behavior by just clicking the same link over and over again).

The event handler here is very awkward, because we're trying not to open the symbol if you double click it to select the text. There's only one code pathway. My best guess is that Chrome has some sort of code which says "if window.open is called more than N milliseconds after a click, open a popup; otherwise, open a new window", and the 250ms timeout we have is hitting that threshold some of the time. Let me see if I can support that theory.

+ @vrana

Yes you are right: it opens differently each time. For me new window opens much more frequently(about 50% of clicks)
The problem looks more complicated that I thought. Thank you for trying to deal with it.

I wrote this test, but every link always opens in a tab, so my "delay" theory is bogus:

<!doctype html>
<html>
  <head>
    <script type="text/javascript">
      function openafter(n) {
        setTimeout(function() {
          window.open('/test/');
        }, n);
        return false;
      }
    </script>
  </head>
  <body>
    <ul>
      <li><a href="#" onclick="openafter(100)">Open After 100ms</a></li>
      <li><a href="#" onclick="openafter(200)">Open After 200ms</a></li>
      <li><a href="#" onclick="openafter(300)">Open After 300ms</a></li>
      <li><a href="#" onclick="openafter(400)">Open After 400ms</a></li>
      <li><a href="#" onclick="openafter(500)">Open After 500ms</a></li>
      <li><a href="#" onclick="openafter(1000)">Open After 1000ms</a></li>
    </ul>
  </body>
</html>

If it help:
My OS is MacOSx 10.8.5
and chrome version is latest: 31.0.1650.57

I have the same Chrome version, although I'm on 10.7.5.

I'm really not sure what's going on here. I can reproduce this less than 2% of the time, and nothing about how I click or the document state seems to impact it. I can't reproduce it in a separate simplified file, or turn up anything via Google about what's going on.

The code itself only has one pathway:

https://secure.phabricator.com/diffusion/P/browse/master/webroot/rsrc/js/application/repository/repository-crossreference.js

So the same code is always executing. I think Chrome is sometimes losing track of the fact that the window.open() is happening in response to a click event (the popup behavior happens if we call window.open() in a raw <script /> tag, for example), but I can't figure out how to trick Chrome into losing this relationship consistently.

Here's a Chromium issue from 2009 which says the browser has a different behavior from the observed behavior (claimed behavior is always open in new window):

http://code.google.com/p/chromium/issues/detail?id=20189

This one looks a lot closer, but isn't really what we're doing:

http://code.google.com/p/chromium/issues/detail?id=162049

I have no idea what's going on. It never happened to me. This seems Chrome specific, maybe we can ask someone working for Google?

epriestley claimed this task.

We haven't seen other reports of this, and we don't have a plan of attack which seems likely to resolve this in a reasonable amount of time given that it's Chrome-specific and reproduction-resistant.