• Tab opening behavior is predictable – it behaves the same 100% of the time. The default behavior in Firefox is determined by a number of factors, too complex to list here. Suffice it to say that changing Firefox’s default tab-opening behavior is like chasing hornets in a hurricane.
• Related tabs are grouped. When I have a thought about something I’m busy doing, and want to start a new search or open a tab related to it, I open a new tab. This addon makes sure that tab is grouped with the current tabs. The default behavior opens that tab at the end of the tab strip, which results in two separate clusters of tabs related to the same task.

• Renaming and migrating to the new manifest format.
• Rewrite the code to use the new WebExtensions APIs.
• Use the new web-ext CLI tool for packaging.

• The id property is necessary in order for addons.mozilla.org (AMO) to match the new add-on with the old one. Remove the top-level id field, and copy its value into the applications/gecko/id field.
• If you used the main property, you’ll now specify your entry point file by the specific functionality, such as background scripts, content_scripts, browser_actions (toolbar buttons), page_actions and options_ui. In my extension, I need to listen to tab events, so I used the background property to load a script.
• The permissions property is used, but differently. The value is now an array instead of an object, and any values you had are likely not supported anymore, and will need to be replaced. You can read about the supported permissions keys and values on the manifest.json permissions page on MDN.

window.tabs.on('open', function(newTab) {
    // do stuff
});

browser.tabs.onCreated.addListener(function(newTab) {
    // do stuff
});

browser.tabs.query({currentWindow: true, active: true}).then(function(tabs) {
    browser.tabs.get(tabs[0].id).then(function(activeTab) {
        // do stuff with the active tab
    });
});

• The WebExtensions API code initializes before the active tab is retrievable, so I needed to add checks for the active tab and no-op if it wasn’t available yet.
• The SDK tabs API didn’t fire when the user reopened a previously-closed tab, but the WebExtensions API does. So I had to add checks to make sure that I didn’t relocate these tabs.
• Another behavior change is that placing a tab adjacent to a pinned tab that’s not the last pinned tab puts it at the end of the tab strip, instead of just putting it at the end of the pinned tabs, like the SDK API did. So now I get all tabs and iterate over them until I find the last pinned tab, and place the tab there manually.

• The WebExtensions API executes tabs.onCreated listeners after the tab is added to the tab strip. This means that with Always Right, if you have a lot of tabs (say, hundreds), you can actually see the tab added to the far end of the tabstrip and then whiz back over to the right of the active tab. It’s dizzying.
• Compounding the problem above, the tab strip scrolls to the new tab, so the currently active tab is scrolled out of view.

• No easy way to test extension behavior across restarts, because I found bugs that only occured on Firefox startup, but development extensions are uninstalled at restart.
• Tabs.onCreated and onRemoved are evaluated at different times – I found this issue while trying to figure out how many tabs it took to be able to make things slow enough to visually see new tabs being relocated in the tabstrip. My Tabcount add-on is here.
• Console error when no _locales dir in unpacked extension
• Tabs.onCreated evaluation is too late to modify index – this is the bug causing the visual relocation of tabs from the end of the tabstrip to the new location.
• Need a way to know whether a new tab is just a previously closed tab being restored – this bug would really help any extensions doing things around where and how new tabs are opened.
• Moving a tab to an index that is a pinned tab adds to end of tab strip instead of next valid index – great opportunity for “do what i want” API design.