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

RESOLVED FIXED in Camino0.9

Status

Camino Graveyard
Tabbed Browsing
RESOLVED FIXED
14 years ago
14 years ago

People

(Reporter: Simon Fraser, Assigned: Geoff "temporarily off bugmail" Beier)

Tracking

unspecified
Camino0.9
PowerPC
Mac OS X

Details

Attachments

(1 attachment)

(Reporter)

Description

14 years ago
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.
-> geoff
Assignee: pinkerton → me
Target Milestone: --- → Camino0.9
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.
(Assignee)

Comment 3

14 years ago
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.
Created attachment 163941 [details]
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).
(Reporter)

Comment 5

14 years ago
See also bug 167689.

Comment 6

14 years ago
(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.
The crashing part is being discussed in bug 269995 (at least AFAIK it's the same
crash).

Comment 8

14 years ago
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

14 years ago
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.
fixed with 269995
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.