265994 - Regression: Can't drop urls/files onto the background of the tab control to have them load

Status: RESOLVED FIXED

(Camino Graveyard :: Tabbed Browsing, defect)

Description

[Simon Fraser [no longer active]]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a4) Gecko/20040926 Camino/0.8+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a4) Gecko/20040926 Camino/0.8+

With the old tab control, you could drag/drop URLs, bookmarks, files etc and
drop them into the background area of the tab control (the space without any
tabs in it); the area would show a blue 'drop highlight', and if you let go, the
item(s) would load in new tab(s).

This no longer happens with the new tab control; it was a nifty little feature
that should be easy to add back.

Reproducible: Always
Steps to Reproduce:
1. Make a new window
2. Make a new tab (so the tab bar is visible)
3. Drag an item from the bookmarks bar, and drag it into the space alongside the
tabs

Actual Results:  
Nothing.

Expected Results:  
The item should load in a new tab.

Comment 1

[Mike Pinkerton (not reading bugmail)]

-> geoff

Comment 2

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

I can't reproduce this on 2004102508 (v0.8+) nightly.  

True, there is no blue highlight, and the (+) globe attached to the pointer
(present over the location bar and the webpage portion of the window) disappears
once you pass on to the background of the tab bar.

However, releasing the dragged webloc/bookmark over the background of the tab
bar (or the "more tabs that don't fit" widget) does in fact create a new tab and
load the dropped webloc/bookmark.

Comment 3

[Geoff "temporarily off bugmail" Beier]

This is intermittent. The only time I can ever reproduce it is in a new window
where there has never been >2 tabs, and even then I can only reproduce under
certain conditions. Even when it works, however, there is no visual feedback.

Comment 4

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

Attachment: Crash log from attempting to drag webloc to tab bar background

I'm seeing it pretty regularly in 20041029 0.8+, whether I have only 2 tabs
open or more than two.	(On one occasion I was able to drag a webloc
successfully with more than two tabs open, but the other ca. 20 tries proved
unsuccessful.)

I'm also randomly getting crashes when attempting to drag weblocs to the tab
bar background with this build, which is a new behavior (and maybe completely
unrelated to this bug, apologies if so).

Comment 5

[Simon Fraser [no longer active]]

See also bug 167689.

Comment 6

[Julian Pellico]

(In reply to comment #3)
> This is intermittent. The only time I can ever reproduce it is in a new window
> where there has never been >2 tabs, and even then I can only reproduce under
> certain conditions. Even when it works, however, there is no visual feedback.
I'll confirm the intermittentness of this issue, as well as the occasional crash.

Comment 7

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

The crashing part is being discussed in bug 269995 (at least AFAIK it's the same
crash).

Comment 8

[Jasper]

Steps to reproduce:

1) fresh start Camino (important)
2) open a window with 2 tabs, best when done by not dragging urls anywhere, just
type.
3) this is the importnat part. drag any file/bm url/page url/webloc to the empty
part of the tab bar without dragging over the existing 2 tabs.
4) result is that the file/bm url/page url/webloc will not be opened.
5) if you do first drag the object over the existing tabs, the object will be
opened in a new tab.

So it appeard that the tab bar isn't registering the drag of the object at
first. It's very possible that the crashes seen while trying to figure out this
bug are the same as bug 269995.

Comment 9

[L. H.]

See bug 269995 comments. prepareForDragOperation: uses mDragDest wrongly. If
mDragDest has not been set ever before then rv = nil and prepareForDragOperation
refuses drop by returning false.

Comment 10

[Mike Pinkerton (not reading bugmail)]

fixed with 269995