Expect websites to open in new tab when entered in address bar

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Make "When pressing enter in address bar with a URL in it, open the URL in a 
new tab" is checked.
2. Enter a URL in the address bar.
3. Press the enter key.

What is the expected output? What do you see instead?
Expect to see new tab open with website of entered URL.
What happens though is that the website comes up in the current tab.

What version of the product are you using? On what operating system?
Google Chrome 20.0.1105.2 dev-m. Chrome Toolbox (by Google) 1.0.29. Windows 7 
Professional.

Please provide any additional information below.
Stopped working about 1 - 2 weeks ago.

Original issue reported on code.google.com by dar...@dandc.com on 23 Apr 2012 at 2:52

[GoogleCodeExporter]

This problem started for me when it was automatically updated to 1.0.30 
yesterday.

Original comment by nutcasej...@gmail.com on 10 May 2012 at 6:56

[GoogleCodeExporter]

This started working again when it was updated to 1.0.31, but it's not working 
now after chrome updated to ver. 19.0.1084.46.

Original comment by nutcasej...@gmail.com on 16 May 2012 at 1:26

[GoogleCodeExporter]

Same issue using Chrome version 19.0.1084.52 m

Original comment by dda...@gmail.com on 28 May 2012 at 12:53

[GoogleCodeExporter]

related issue, when entering a search term in the address bar, a new tab is 
always opened when pressing enter.  This appears to be incorrect behavior.

Original comment by i...@systemstreet.com on 22 Jun 2012 at 9:53

[GoogleCodeExporter]

This is now happenning with me. I think the problem is recent, it was working 
earlier.
Chrome version 23.0.1271.64 m
Toolbox re-downloaded today.

Original comment by rogd...@gmail.com on 29 Jan 2013 at 2:28

[GoogleCodeExporter]

I have this problem too

Original comment by wilshere...@gmail.com on 21 Aug 2013 at 9:41

[GoogleCodeExporter]

I have the same issue
It started a few days ago on my Windows XP 32bit machine at work.
On my Windows 7 64bit machine at home everything still works fine.
I have Chrome synced on both.

Chrome: 29.0.1547.57 m
Google Toolbox: 1.0.32

Original comment by kaddour....@gmail.com on 22 Aug 2013 at 10:46

[GoogleCodeExporter]

I hate saying "me too" but "me too"

Version 29.0.1547.57 m chrome

latest toolbox installed

just started happening today - nothing changed

Windows 7.

works fine on my windows XP virtual machine running on that windows 7 machine, 
just not on the windows 7 machine.

Original comment by tkyt...@gmail.com on 23 Aug 2013 at 8:33

[GoogleCodeExporter]

Ok, I just updated my chrome version in my windows Xp vm to 29 and viola - it 
is now also broken.  

chrome v29 breaks this feature offered by the extension.

Original comment by tkyt...@gmail.com on 23 Aug 2013 at 8:39

[GoogleCodeExporter]

Me too ;-)

Version 29.0.1547.57 m chrome
latest toolbox installed

Original comment by ernst.zo...@gmail.com on 26 Aug 2013 at 5:36

[GoogleCodeExporter]

Ditto. v29 broke this feature. This was the only extension's function that is 
keeping me form going back to FF. 

Original comment by haynes.c...@gmail.com on 26 Aug 2013 at 6:22

[GoogleCodeExporter]

I have the same issue since a few days, I think it happened with version 
29.0.1547.57m - but I just updated to 29.0.1547.62m and it still does not 
function.

Original comment by skod-ma...@hotmail.com on 27 Aug 2013 at 7:47

[GoogleCodeExporter]

Ditto. Please fix this as toolbox is now useless to me without this feature. 
Thank God i found this thread. it was driving me bonkers. 3 installs, 3 
different old versions and lots of swearing later, i have found i'm not alone. 
grrrrrr...

Original comment by eghar...@gmail.com on 27 Aug 2013 at 9:19

[GoogleCodeExporter]

At my desk:
Chrome Version 29.0.1547.62 m     (today updated)

Chrome Toolbox (by Google) 1.0.32

And exactly the same problem as shown above....

Original comment by antoni.a...@gmail.com on 28 Aug 2013 at 6:48

[GoogleCodeExporter]

I tried beta v30.0.1.1599.14 beta-m. Still no luck...

Original comment by eghar...@gmail.com on 28 Aug 2013 at 1:40

[GoogleCodeExporter]

Same issue on 30.0.1599.22 beta-m

Original comment by eghar...@gmail.com on 28 Aug 2013 at 3:49

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

See related thread here - maybe star the issue to let folks know at Chromium 
that this is a problem, since Chrome is what broke the extension.

https://code.google.com/p/chromium/issues/detail?id=244086

Original comment by michael....@gmail.com on 29 Aug 2013 at 4:29

[GoogleCodeExporter]

I've done some quick investigation. The problem almost certainly is in that the 
extension's code uses deprecated APIs for communicating between the content 
script and the background page. 

floating_bar.js:561 has:

    chrome.extension.sendRequest({...

and background.js:91 has:

    chrome.extension.onRequest.addListener(function(...

These were deprecated as of Chrome 20 in favor of chrome.runtime.sendMessage 
and chrome.runtiome.onMessage.addListener, respectively. See the announcement 
and the changelist here:

http://developer.chrome.com/extensions/whats_new.html
https://groups.google.com/a/chromium.org/forum/#!msg/chromium-reviews/fU4F5-77DU
w/xnnbd7-RTsQJ

So, the "deprecated" status has been in place for over a year now. Until this 
extension switches to the new APIs, all bets are off.

Original comment by serge...@chromium.org on 12 Sep 2013 at 12:02

[GoogleCodeExporter]

I doubt the use of sendRequest is the issue. The API is deprecated, but should 
still work.

Question for the extension authors: how do you implement this feature? Knowing 
that would help us figure out what we did to Chrome to break it.

Original comment by mpcomplete@chromium.org on 12 Sep 2013 at 11:40

[GoogleCodeExporter]

Thanks for considering. The problem is that the extension hasn't been
updated in a year, nor has any bug been looked at in a year. I might look
at the code and see if I can find it. I do know that it was broken and
fixed before between the other versions listed in the other thread.

Original comment by michael....@gmail.com on 13 Sep 2013 at 1:47

[GoogleCodeExporter]

Thanks for considering. The problem is that the extension hasn't been updated 
in a year, nor has any bug been looked at in a year. I might look at the code 
and see if I can find it. I do know that it was broken and fixed before between 
the other versions listed in the other thread.

Original comment by michael....@gmail.com on 13 Sep 2013 at 1:47

[GoogleCodeExporter]

OK, here is the code. From client_process_functions.cc
LRESULT CALLBACK GetMsgProc(int code, WPARAM wParam, LPARAM lParam){
  if (client_thread_handle == INVALID_HANDLE_VALUE) {
    client_thread_handle = CreateThread(NULL, 0, Client_Thread, NULL, 0, 
                                        NULL);
  }
  MSG* msg = (MSG*)lParam;

  // Check user press enter key in the address bar.
  if (msg->message == WM_KEYDOWN && msg->wParam == VK_RETURN &&
      press_enter_open_new_tab) {
    HWND chrome_hwnd = GetParent(msg->hwnd);
    if (chrome_hwnd) {
      ChromeWindowIdMap::iterator iter = chrome_window_map.find(chrome_hwnd);
      if (iter != chrome_window_map.end()) {
       TCHAR class_name[256];
        GetClassName(msg->hwnd, class_name, 256);
        if (_tcscmp(class_name, kAddressBarClassName) == 0 ||
            _tcscmp(class_name, kOmniboxViewClassName) == 0) {
          CmdMsgItem item;
          item.cmd = kCmdPressEnterOpenNewTab;
          WriteToServer(item);
          msg->message = WM_NULL;
        }
      }
    }
  }

from convenience_plugin.cc (in a long case statement):
case kCmdPressEnterOpenNewTab:
          PostMessage(plugin->get_hwnd(), WM_PRESS_ENTER_OPEN_NEW_TAB, 0, 0);
          break;

Also:
void ConveniencePlugin::PressEnterOpenNewTab(bool flag) {
  CmdMsgItem item;
  item.cmd = kCmdUpdatePressEnterOpenNewTab;
  item.value.press_enter_open_new_tab = flag;
  press_enter_open_new_tab_ = flag;
  WriteToClient(item);
}

from stdafx.h:
#define WM_PRESS_ENTER_OPEN_NEW_TAB   WM_USER+108

From Convenience_plugin.cc: (defining writetoclient)
void ConveniencePlugin::WriteToClient(const CmdMsgItem& item) {
  char logs[256];
  sprintf(logs, "WriteToClient, cmd=%d", item.cmd);
  DWORD writelen;
  if (WriteFile(server_pipe_handle_, &item, sizeof(item), &writelen, NULL))
    g_log.WriteLog("Send", logs);
  else
    g_log.WriteLog("Send Error", logs);
}

finally, from plugin_base.cc (sethwnd) - which sets the wnd for get_hwnd for 
the post message:
NPError PluginBase::SetWindow(NPWindow* window) {
  window_ = (HWND)window->window;
  return NPERR_NO_ERROR;
}

Original comment by michael....@gmail.com on 13 Sep 2013 at 2:08

[GoogleCodeExporter]

Finally, the "WriteFile" appears to write to a client thread started with this 
function (Only pasting the first part from client_process_function.cc):
DWORD WINAPI Client_Thread(void* param) {
  char szLog[256];
  char buffer[MAX_BUFFER_LEN];
  DWORD outlen;
  int offset = 0;
  int readlen = sizeof(CmdMsgItem);
  CmdMsgItem cmd;

  OVERLAPPED ol = { 0 };
  ol.hEvent = CreateEvent(NULL, FALSE, FALSE, NULL);
  TCHAR pipe_name[MAX_PATH];
  _stprintf(pipe_name, _T("%s_%ld"), kPipeName, 
            ReadBaseInfomation(_T("CFG"), _T("PID")));
  ReadBaseInfomation(_T("CFG"), _T("CLASSNAME"), g_ChromeClassName, MAX_PATH);

  while(true) {
    client_pipe_handle = CreateFile(pipe_name, GENERIC_READ | GENERIC_WRITE,
                                    0, NULL, OPEN_EXISTING, 
                                    FILE_FLAG_OVERLAPPED, NULL);

    if (client_pipe_handle == INVALID_HANDLE_VALUE) {
      DWORD errorcode = GetLastError();
      if (errorcode == ERROR_PIPE_BUSY) {
        sprintf(szLog, "CreateFile Failed,GetLastError=%ld", errorcode);
        g_log.WriteLog("Error", szLog);
        Sleep(10);
        continue;
      } else {
        sprintf(szLog, "CreateFile Failed,GetLastError=%ld", errorcode);
        g_log.WriteLog("Error", szLog);
        Sleep(10);
        continue;
      }
    } else {
      g_log.WriteLog("Msg", "CreateFile success, start client thread");
    }

Original comment by michael....@gmail.com on 13 Sep 2013 at 2:19

[GoogleCodeExporter]

Oh I see, you're using native code to hook into the omnibox window. I suspect 
this change is what broke your extension, then: 
http://src.chromium.org/viewvc/chrome?revision=193202&view=revision

That makes it so the omnibox is no longer a separate HWND, but a custom widget 
that we draw into, AFAIK.

Unfortunately, since you're hooking into Chrome directly and not using a public 
API, it's very fragile and likely to break without warning. There's not much we 
can do to help you.

Original comment by mpcomplete@chromium.org on 18 Sep 2013 at 1:18

[GoogleCodeExporter]

Thanks for at least pointing to the change.

Original comment by michael....@gmail.com on 18 Sep 2013 at 11:43

[GoogleCodeExporter]

http://blog.chromium.org/2013/09/saying-goodbye-to-our-old-friend-npapi.html

Original comment by dbr...@gmail.com on 24 Sep 2013 at 1:03