Closed Bug 583735 Opened 10 years ago Closed 9 years ago

Dragging links to between tabs no longer opens links in new tab between those tabs


(Firefox :: Tabbed Browser, defect)

Not set



Firefox 4.0b7
Tracking Status
blocking2.0 --- betaN+


(Reporter: netrolller.3d, Assigned: dao)



(Keywords: regression, Whiteboard: fixed by bug 320638)

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.
Keywords: regression
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.
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:

Hm, can't really find a bug in that list which could be related. is another potential candidate.
(In reply to comment #5)
> 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?
(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.
Assignee: nobody → enndeakin
blocking2.0: ? → betaN+
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.
Assignee: enndeakin → dao
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.
Depends on: 320638
Whiteboard: patch in bug 320638
Duplicate of this bug: 576354
OS: Windows 7 → All
Hardware: x86 → All
Whiteboard: patch in bug 320638 → patch in bug 320638 [needs review]
Closed: 9 years ago
Resolution: --- → FIXED
Whiteboard: patch in bug 320638 [needs review] → fixed by bug 320638
Target Milestone: --- → Firefox 4.0b6
You need to log in before you can comment on or make changes to this bug.