Open In Chrome Version History

10 versions

Be careful with old versions!

These versions are displayed for reference and testing purposes. You should always use the latest version of an add-on.

Version 1.6.0 33.3 kB Works with Firefox 3.6 and later

Change since v1.5.3
  • New: Grouped tabs can now be excluded from those being migrated.
  • Changed: Moved open current tab before open all in the menus as per user request, since it seems more common to migrate individual tabs than all of them.
  • Lingering bug and workaround
    • Issue: If no Google Chrome browser window is opened, migration of "all tabs" from Firefox (may) result in each tab landing in a separate chrome window, instead of as separate tabs in the same Chrome window.
    • Workaround: Make sure at least one Google Chrome window is opened before migrating a whole set of tabs ("all tabs").
    • Comment: This problem was reported by a user previously, but I was unable to reproduce it at that time. It seems the issue is a timing issue (race condition) which results in an undersirable side effect, stemming from how Google has designed the Chrome browser's startup.

      When the first Chrome process (window) starts up, it creates a "command and control" process (a book keeper) that keeps track of a bunch of details for each of the browser's tabs and windows. Until that process is started and a Chrome browser window has been brought up, the logic for reusing windows by opening tabs instead of new windows is not available to that browser.

      When my addon spews out a bunch of URLs to a non-running Chrome, the browser might not have time to start up the "command and control" process before a number of URLs have already been sent to that browser, and Chrome consequently ("stupidly") then creates new windows for each of the migrated tabs.

      There are two ways to address this. One you likely won't appreciate and one you would. The bad one is me injecting a delay after the first URL has been sent to Chrome, each time you trigger the tab "batch migration", so as to reduce the probability that Chrome hasn't fully started when the subsequent URLs hit it. The good solution would be for Google to simply queue up URLs sent to its browser and defer the decision of whether to open windows or tabs until at least their book keeping process has had time to start.

      Let me know whether you'd like me to "slow down" the batch-migration, or whether you can live with opening a Chrome instance by hand (or through my extension by initially only migrating a single tab).

      Also note that you may not experience this issue at all. Myself I don't experience this problem on OS X or Ubuntu and didn't have it on Windows until last year. If you're one of the people suffering from the problem, then simply launch Chrome before using this addon, as I now do on Windows 7.

Version 1.5.3 33.1 kB Works with Firefox 3.6 and later

Change since v1.5.2
  • ChangedAdded a note in the help popup for the chrome path field clarifying that a path with spaces must be quoted. This is especially relevant for windows users that enter the path by hand, instead of browsing for the command.
  • Lingering bug and workaround
    • Issue: If no Google Chrome browser window is opened, migration of "all tabs" from Firefox (may) result in each tab landing in a separate chrome window, instead of as separate tabs in the same Chrome window.
    • Workaround: Make sure at least one Google Chrome window is opened before migrating a whole set of tabs ("all tabs").
    • Comment: This problem was reported by a user previously, but I was unable to reproduce it at that time. It seems the issue is a timing issue (race condition) which results in an undersirable side effect, stemming from how Google has designed the Chrome browser's startup.

      When the first Chrome process (window) starts up, it creates a "command and control" process (a book keeper) that keeps track of a bunch of details for each of the browser's tabs and windows. Until that process is started and a Chrome browser window has been brought up, the logic for reusing windows by opening tabs instead of new windows is not available to that browser.

      When my addon spews out a bunch of URLs to a non-running Chrome, the browser might not have time to start up the "command and control" process before a number of URLs have already been sent to that browser, and Chrome consequently ("stupidly") then creates new windows for each of the migrated tabs.

      There are two ways to address this. One you likely won't appreciate and one you would. The bad one is me injecting a delay after the first URL has been sent to Chrome, each time you trigger the tab "batch migration", so as to reduce the probability that Chrome hasn't fully started when the subsequent URLs hit it. The good solution would be for Google to simply queue up URLs sent to its browser and defer the decision of whether to open windows or tabs until at least their book keeping process has had time to start.

      Let me know whether you'd like me to "slow down" the batch-migration, or whether you can live with opening a Chrome instance by hand (or through my extension by initially only migrating a single tab).

      Also note that you may not experience this issue at all. Myself I don't experience this problem on OS X or Ubuntu and didn't have it on Windows until last year. If you're one of the people suffering from the problem, then simply launch Chrome before using this addon, as I now do on Windows 7.

Version 1.5.2 33.0 kB Works with Firefox 3.6 and later

Change since v1.5.1
  • New: Open links in Google Chrome through a mouse click. This feature was previously available only through the context menu (right-clicking a link). The preference page has been updated to allow some customization regarding under what specific circumstance a clicked link should be opened on Google Chrome.
  • Lingering bug and workaround
    • Issue: If no Google Chrome browser window is opened, migration of "all tabs" from Firefox (may) result in each tab landing in a separate chrome window, instead of as separate tabs in the same Chrome window.
    • Workaround: Make sure at least one Google Chrome window is opened before migrating a whole set of tabs ("all tabs").
    • Comment: This problem was reported by a user previously, but I was unable to reproduce it at that time. It seems the issue is a timing issue (race condition) which results in an undersirable side effect, stemming from how Google has designed the Chrome browser's startup.

      When the first Chrome process (window) starts up, it creates a "command and control" process (a book keeper) that keeps track of a bunch of details for each of the browser's tabs and windows. Until that process is started and a Chrome browser window has been brought up, the logic for reusing windows by opening tabs instead of new windows is not available to that browser.

      When my addon spews out a bunch of URLs to a non-running Chrome, the browser might not have time to start up the "command and control" process before a number of URLs have already been sent to that browser, and Chrome consequently ("stupidly") then creates new windows for each of the migrated tabs.

      There are two ways to address this. One you likely won't appreciate and one you would. The bad one is me injecting a delay after the first URL has been sent to Chrome, each time you trigger the tab "batch migration", so as to reduce the probability that Chrome hasn't fully started when the subsequent URLs hit it. The good solution would be for Google to simply queue up URLs sent to its browser and defer the decision of whether to open windows or tabs until at least their book keeping process has had time to start.

      Let me know whether you'd like me to "slow down" the batch-migration, or whether you can live with opening a Chrome instance by hand (or through my extension by initially only migrating a single tab).

      Also note that you may not experience this issue at all. Myself I don't experience this problem on OS X or Ubuntu and didn't have it on Windows until last year. If you're one of the people suffering from the problem, then simply launch Chrome before using this addon, as I now do on Windows 7.

Version 1.5.1 31.2 kB Works with Firefox 3.6 and later

Changes since 1.4.0
  • New: Added a preference option to ignore pinned tabs.
  • New: Open links in Chrome. When triggering the context menu on a link, a menu item is listed for opening that link in Google Chrome.
  • Changed: The tooltip for the icon, to be less annoying.
  • Lingering bug and workaround
    • Issue: If no Google Chrome browser window is opened, migration of "all tabs" from Firefox (may) result in each tab landing in a separate chrome window, instead of as separate tabs in the same Chrome window.
    • Workaround: Make sure at least one Google Chrome window is opened before migrating a whole set of tabs ("all tabs").
    • Comment: This problem was reported by a user previously, but I was unable to reproduce it at that time. It seems the issue is a timing issue (race condition) which results in an undersirable side effect, stemming from how Google has designed the Chrome browser's startup.

      When the first Chrome process (window) starts up, it creates a "command and control" process (a book keeper) that keeps track of a bunch of details for each of the browser's tabs and windows. Until that process is started and a Chrome browser window has been brought up, the logic for reusing windows by opening tabs instead of new windows is not available to that browser.

      When my addon spews out a bunch of URLs to a non-running Chrome, the browser might not have time to start up the "command and control" process before a number of URLs have already been sent to that browser, and Chrome consequently ("stupidly") then creates new windows for each of the migrated tabs.

      There are two ways to address this. One you likely won't appreciate and one you would. The bad one is me injecting a delay after the first URL has been sent to Chrome, each time you trigger the tab "batch migration", so as to reduce the probability that Chrome hasn't fully started when the subsequent URLs hit it. The good solution would be for Google to simply queue up URLs sent to its browser and defer the decision of whether to open windows or tabs until at least their book keeping process has had time to start.

      Let me know whether you'd like me to "slow down" the batch-migration, or whether you can live with opening a Chrome instance by hand (or through my extension by initially only migrating a single tab).

      Also note that you may not experience this issue at all. Myself I don't experience this problem on OS X or Ubuntu and didn't have it on Windows until last year. If you're one of the people suffering from the problem, then simply launch Chrome before using this addon, as I now do on Windows 7.

Version 1.4.0 29.7 kB Works with Firefox 3.6 and later

  • New: Added option to automatically close migrated tabs. When this feature is enabled, all except the last tab will be eligible for being closed automatically, since the entire FF browser exists when the last tab is closed (which I've assumed people don't want).
  • New: Added tracing option to help identify and resolve issues, should anyone face any. This feature was previously hidden and required explicit activation using the firefox preference system (about:config). Now there is no need to muck around in the FF prefs-system and instead the tracing is enabled and disabled via a checkbox in the addon's options page.
  • Lingering bug and workaround
    • Issue: If no Google Chrome browser window is opened, migration of "all tabs" from Firefox (may) result in each tab landing in a separate chrome window, instead of as separate tabs in the same Chrome window.
    • Workaround: Make sure at least one Google Chrome window is opened before migrating a whole set of tabs ("all tabs").
    • Comment: This problem was reported by a user previously, but I was unable to reproduce it at that time. It seems the issue is a timing issue (race condition) which results in an undersirable side effect, stemming from how Google has designed the Chrome browser's startup.

      When the first Chrome process (window) starts up, it creates a "command and control" process (a book keeper) that keeps track of a bunch of details for each of the browser's tabs and windows. Until that process is started and a Chrome browser window has been brought up, the logic for reusing windows by opening tabs instead of new windows is not available to that browser.

      When my addon spews out a bunch of URLs to a non-running Chrome, the browser might not have time to start up the "command and control" process before a number of URLs have already been sent to that browser, and Chrome consequently ("stupidly") then creates new windows for each of the migrated tabs.

      There are two ways to address this. One you likely won't appreciate and one you would. The bad one is me injecting a delay after the first URL has been sent to Chrome, each time you trigger the tab "batch migration", so as to reduce the probability that Chrome hasn't fully started when the subsequent URLs hit it. The good solution would be for Google to simply queue up URLs sent to its browser and defer the decision of whether to open windows or tabs until at least their book keeping process has had time to start.

      Let me know whether you'd like me to "slow down" the batch-migration, or whether you can live with opening a Chrome instance by hand (or through my extension by initially only migrating a single tab).

      Also note that you may not experience this issue at all. Myself I don't experience this problem on OS X or Ubuntu and didn't have it on Windows until a few weeks ago. If you're one of the people suffering from the problem, then simply launch Chrome before using this addon, as I now do on Windows 7.

Version 1.3.8 29.7 kB Works with Firefox 3.6 and later

Minor fix, the addon no longer displays shows up on the context menu for contexts it where its use is not likely to be wanted. Explicitly if a user is on a non-HTTP(s) URL, has text selected and is clicking on the selection or when right-clicking on any of the following: links, images, input fields, text areas or buttons.

Version 1.3.5 27.6 kB Works with Firefox 3.6 and later

  • Fix: Bug that caused nothing to happen when the addon was clicked, even on a page with a supported URL scheme.
    The problem manifested itself if Chrome was installed using a non-admin windows account *and* it was installed into a directory with space(s) in the path, such as "Program Files" on windows.
  • Lingering bug and workaround
    • Issue: If no Google Chrome browser window is opened, migration of "all tabs" from Firefox (may) result in each tab landing in a separate chrome window, instead of as separate tabs in the same Chrome window.
    • Workaround: Make sure at least one Google Chrome window is opened before migrating a whole set of tabs ("all tabs").
    • Comment: This problem was reported by a user previously, but I was unable to reproduce it at that time. It seems the issue is a timing issue (race condition) which results in an undersirable side effect, stemming from how Google has designed the Chrome browser's startup.

      When the first Chrome process (window) starts up, it creates a "command and control" process (a book keeper) that keeps track of a bunch of details for each of the browser's tabs and windows. Until that process is started and a Chrome browser window has been brought up, the logic for reusing windows by opening tabs instead of new windows is not available to that browser.

      When my addon spews out a bunch of URLs to a non-running Chrome, the browser might not have time to start up the "command and control" process before a number of URLs have already been sent to that browser, and Chrome consequently ("stupidly") then creates new windows for each of the migrated tabs.

      There are two ways to address this. One you likely won't appreciate and one you would. The bad one is me injecting a delay after the first URL has been sent to Chrome, each time you trigger the tab "batch migration", so as to reduce the probability that Chrome hasn't fully started when the subsequent URLs hit it. The good solution would be for Google to simply queue up URLs sent to its browser and defer the decision of whether to open windows or tabs until at least their book keeping process has had time to start.

      Let me know whether you'd like me to "slow down" the batch-migration, or whether you can live with opening a Chrome instance by hand (or through my extension by initially only migrating a single tab).

      Also note that you may not experience this issue at all. Myself I don't experience this problem on OS X or Ubuntu and didn't have it on Windows until a few weeks ago. If you're one of the people suffering from the problem, then simply launch Chrome before using this addon, as I now do on Windows 7.

Version 1.3.2 23.6 kB Works with Firefox 3.6 and later

V1.3.2
  • Enhancement: Added "auto configuration" for OSX, so Mac users can start using the addon immediately, without having to configure anything. (Same convenience already awarded Windows users).
V1.3.1
  • Fix: v1.3.0 was broken on OSX and remedied in this version, where it has been tested successfully on Lion.
  • Fix: Fixed command line parsing, so that quoted strings/arguments/paths are now correctly handled for the command to launch Chrome.
V1.3.0
  • New: A preference for showing the addon's commands in the context menu, by right-clicking somewhere within a tab.
  • New: Flexibility in deciding how the commands are triggered when clicking on the addon's icon. I've provided a bit more options than has been requested so far in the hope that it should allow enough variants to satisfy also preferences not yet voiced.
  • Lingering bug and workaround
    • Issue: If no Google Chrome browser window is opened, migration of "all tabs" from Firefox (may) result in each tab landing in a separate chrome window, instead of as separate tabs in the same Chrome window.
    • Workaround: Make sure at least one Google Chrome window is opened before migrating a whole set of tabs ("all tabs").
    • Comment: This problem was reported by a user previously, but I was unable to reproduce it at that time. It seems the issue is a timing issue (race condition) which results in an undersirable side effect, stemming from how Google has designed the Chrome browser's startup.

      When the first Chrome process (window) starts up, it creates a "command and control" process (a book keeper) that keeps track of a bunch of details for each of the browser's tabs and windows. Until that process is started and a Chrome browser window has been brought up, the logic for reusing windows by opening tabs instead of new windows is not available to that browser.

      When my addon spews out a bunch of URLs to a non-running Chrome, the browser might not have time to start up the "command and control" process before a number of URLs have already been sent to that browser, and Chrome consequently ("stupidly") then creates new windows for each of the migrated tabs.

      There are two ways to address this. One you likely won't appreciate and one you would. The bad one is me injecting a delay after the first URL has been sent to Chrome, each time you trigger the tab "batch migration", so as to reduce the probability that Chrome hasn't fully started when the subsequent URLs hit it. The good solution would be for Google to simply queue up URLs sent to its browser and defer the decision of whether to open windows or tabs until at least their book keeping process has had time to start.

      Let me know whether you'd like me to "slow down" the batch-migration, or whether you can live with opening a Chrome instance by hand (or through my extension by initially only migrating a single tab).

      Also note that you may not experience this issue at all. Myself I don't experience this problem on OS X or Ubuntu and didn't have it on Windows until a few weeks ago. If you're one of the people suffering from the problem, then simply launch Chrome before using this addon, as I now do on Windows 7.
V1.2.0
  • New: Command options now supported for the chrome executable (user requested feature). Simply add them after the path to the Chrome browser executable, in options window.

Version 1.1.2 16.4 kB Works with Firefox 3.6 and later

Fixed a minor typo in the settings window.

Version 1.0 11.3 kB Works with Firefox 3.6 and later