If you wish to drag and drop to rearrange the previews in the tab preview window, it should do so. Also, it should match the rearrangement by moving the tabs on the tab bar.

This was surprisingly trivial, thanks to the solid drag and drop API and due to the fact that browser-tabPreviews.js handled the TabMove event already.

Oh, so then it is a duplicate. Wow, I thought you would never get to this! Thanks :)

Comment on attachment 421818 [details] [diff] [review] patch >+ <handler event="dragover"><![CDATA[ >+ if (event.dataTransfer.types.contains("application/x-moz-node")) You may want to check the (tab.parentNode == gBrowser.tabContainer) condition here in the dragover listener as well. >+ <handler event="drop"><![CDATA[ >+ let tab = event.dataTransfer.mozGetDataAt("application/x-moz-node", 0); >+ if (tab && tab.parentNode == gBrowser.tabContainer) { >+ let newIndex = Array.indexOf(gBrowser.tabContainer.childNodes, this._tab); >+ gBrowser.moveTabTo(tab, newIndex); >+ } >+ ]]></handler> Is there a gap between or at the ends of the preview buttons where the user might want to drop? The above would only support dropping right on another button, no?

(In reply to comment #5) > You may want to check the (tab.parentNode == gBrowser.tabContainer) condition > here in the dragover listener as well. Makes sense. > Is there a gap between or at the ends of the preview buttons where the user > might want to drop? The above would only support dropping right on another > button, no? There are no gaps between the previews. There can be space at the end; for instance, if there were 7 previews in 3 rows, there would be two empty slots. However, the previews' container doesn't have a visible border, so it would probably feel odd if the drop zone equaled the container.

V Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a2pre) Gecko/20100206 Minefield/3.7a2pre ID:20100206050229