Up to Firefox 3.6, it was possible to duplicate the active tab by dragging the favicon from the Awesomebar to a space between tabs or to the end of the tabstrips. In Firefox 4, dragging to between tabs no longer has the desired effect (it will instead replace the contents of one of the tabs the mouse is between with the contents of the active tab). Dragging to the end of the tab bar still works, but the ability to duplicate a tab to a specific place on the tab bar is lost. The same problem applies to dragging bookmarks from the Bookmarks toolbar, menu, or side panel to the tab bar, and more importantly; when dragging links from an open page to the tab bar. The blue arrow for creating a new tab only shows up when dragging to the very end of the tab bar, so a new tab can only be created with the wanted context at the end of the bar. I used this feature (especially the ability to drag links to the tab bar and open a new tab from them at that specific location) a lot, so its absence is quite annoying now. Steps to reproduce (1): 1. Open 2 tabs. 2. In one tab, load a page that contains a link. 3. Drag the link to the tab bar, between the 2 existing tabs. Steps to reproduce (2): 1. Open 2 tabs. 2. Load a page in one tab. 3. Drag the favicon from the location bar to the area between the 2 tabs. Steps to reproduce (3): 1. Open 2 tabs. 2. Drag a bookmark from the Bookmarks menu or the Bookmarks Toolbar to the space between the 2 tabs. Expected results: A new tab is opened between the 2 existing tabs, containing the target of the link (1), a copy of the active page (2), or the target of a bookmark (3). Actual results: Rather than creating a new tab, one of the 2 tabs will be overwritten with the contents that should appear in the new tab.

Gabor, would you have time to check for the regression range? That would be really helpful. I think that regression should block the release -> asking for blocking2.0.

Works: 2010041903 Broken: 2010042004 The tab strip in the broken build also looks vastly different from the one in the previous build; I wonder if it is related to the regression. I can't hunt for the exact bug number now, as the Hg web viewer is broken, and refuses to show anything other than the most recent commits (no links to access older commits in shortlog/changelog mode). Note that in pre-0420 builds with the tabs-on-top feature included, when the tabs are on top, it is quite hard to drag items to the right place between tabs (only a few pixels of active area, and the blue arrow is missing), but it is possible. In the 0420 build, even with tabs on bottom, dragging still fails.

Thanks for nailing that regression range. Changesets would have been fine but I got those via the FTP server: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=85c3175de68f&tochange=5f229488969c Hm, can't really find a bug in that list which could be related.

http://hg.mozilla.org/mozilla-central/rev/625e6d4219ab is in that range.

http://hg.mozilla.org/mozilla-central/rev/58c9dd4f0c1f is another potential candidate.

(In reply to comment #5) > http://hg.mozilla.org/mozilla-central/rev/58c9dd4f0c1f is another potential > candidate. I don't see anything in there that *should* affect dragging links between tabs. So if it really made a difference, this would probably mean that there was already some other code broken underneath.

So bug 545714 introduced this regression which was made visible by the checkin of bug 560166?

Maybe.

(In reply to comment #7) > So bug 545714 introduced this regression which was made visible by the checkin > of bug 560166? Neil, could that be a regression from your patch on bug 545714 (Consolidate browser and nsContentAreaDragDrop.cpp dropped link handlers)?

Neil, if you can confirm this wasn't caused by your patch, please let johnath know and he'll get it reassigned.

After some testing I think this is caused by Dao's patch to bug 549061 which changed the padding/border/margins on tabs. I think what's happening here is that the area between tabs in now either very thin, or 0 such that dropping something between tabs isn't possible any more. When _getDragTargetTab is called in the drop handler, a tab being dropped over is always returned. Before, null was returned, indicating a drop not directly on a tab but on the tabbar or gap between tabs.

See comment 6 - If borders and padding made this work previously, that's a bug. There has never been any space (e.g. margins) between tabs.