339404 - Drag and drop of a folder or tab group onto an existing tab replaces from beginning, not from drag target location

Status: RESOLVED INCOMPLETE

(Camino Graveyard :: Drag & Drop, defect)

Description

[Chris Lawson (gone)]

When dropping a folder or tab group onto an extant tab that is not the left-most tab in a window, the tabs are replaced starting with the left-most tab in the window (rather than the drag target tab, appending new tabs at the right if necessary). This seems a little weird at best, and downright wrong at worst.

My initial thought was to add a fourth behaviour to the eOpenTabsPolicy enum, but I wanted to get some commentary from the people who matter before jumping into it.

Comment 1

[Chris Lawson (gone)]

BTW, the reason eReplaceFromCurrentTab doesn't work is that it's intended to replace from the current foreground tab. This would be fine if drag targets were only ever foreground tabs, but its behaviour is at least as broken as the current mess when targeting background tabs with a drag (I tried it, and it ain't pretty). That's why I suggested creating a fourth behaviour.

cl

Comment 2

[Håkan Waara]

What would the new enum constant be? Since the drag can happen on any background tab, you'll need to tell which tab to start from, I don't think you can do that with a constant.

You could move the logic from openURLArray: (or whatever you want to use) to a new method with a startFromTab: parameter. If you do that, please have the existing openURLArray: call it, with some default param, so you don't have to modify all callers.

Comment 3

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

This doesn't seem like it's going to make 1.1 based on its current state.

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Mass un-setting milestone per 1.6 roadmap.

Filter on RemoveRedonkulousBuglist to remove bugspam.

Developers: if you have a patch in hand for one of these bugs, you may pull the bug back to 1.6 *at that point*.