Closed Bug 206987 Opened 21 years ago Closed 12 years ago

Dragging folders around personal toolbar does not rearrange the order (unless Alt or Shift are held pressed)

Categories

(SeaMonkey :: Bookmarks & History, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: bbaylor, Unassigned)

References

Details

(Whiteboard: [2012 Fall Equinox])

User-Agent:       Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507

In v1.2.1 of Mozilla, I had folders (with links inside) and a few links (not in 
folders) on the personal toolbar. I rearranged the order to my liking by 
dragging them to a new position. On Mozilla 1.4b, dragging folders to rearrange 
no longer works. Dragging links does work though. When dragging folders the 
little vertical line indicating the new placement doesn't draw and no movement 
of folders occurs. 

Reproducible: Always

Steps to Reproduce:
1. Put cursor over a personal toolbar folder.
2. Left click and hold and try to drag elsewhere on the personal toolbar.
3. Release click 
Actual Results:  
Nothing happens.


Expected Results:  
Rearrangement should occur. 

ATI 8500DV video card with Catalyst 3.2 drivers. Win2k SP2. I did a full 
uninstall of the old Mozilla and deleted its folders, before install of v1.4b.
I just discovered that pressing alt while dragging makes the little vertical 
line appear and the folder moves to the desired position as expected. It should 
work without pressing alt like v1.2.1 allows.
Ack! Now the alt trick isn't working after I added a new folder to the personal
toolbar. The vertical line draws but no movement occurs. I tried closing Mozilla
(and the quick launch) and reopening but it still doesn't work. I'll try it
again next time I reboot. 
This works for me with the 2003-05-23-09 Win32 trunk build (while pressing down
the ALT) under Win Xp. Reporter, can you try the latest build ?
I can confirm this in 
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030606

The ALT method works for me, but yes... It should work without the ALT key..
I believe that this is intended behavior. 
Hmmm, this situation does not leave me with a good feeling inside.  Two reasons.
 I can confirm that the ATL key allows one to move around folders and bookmarks
alike in the personal toolbar folder (using FireFox 0.8).  However, it seems
that only links can be moved without the modifier key.  I tend to agree that
being able to drag links and folders on toolbars borders on too much control
(new users could accidently rearrange things trying to click on them, I have
watched it happen).  The requirement of the modifier key, IMHO, is the perfect
"hidden" solution.  

Either way, let's make this consistent.  Dragging links and folders on the
toolbar either requires the ALT key or it doesn't, not one of each.
See also bug 235244, same bug for Firefox.
After using the ALT key to move a folder on the Toolbar, and then releasing it,
the File Menu becomes selected.  It shouldn't.
Product: Browser → Seamonkey
The angle-drag suggested in Firefox bug 235244 seems like a good idea.
Confirming this bug for Seamonkey.

Prog.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Dragging folders around personal toolbar does not rearrange the order. → Dragging folders around personal toolbar does not rearrange the order (unless Alt or Shift are held pressed)
Reassigning as per Bug #32644
Assignee: p_ch → nobody
Severity: major → normal
QA Contact: chrispetersen → bookmarks
*** Bug 146448 has been marked as a duplicate of this bug. ***
*** Bug 303850 has been marked as a duplicate of this bug. ***
WFM here, no modifiers need to be pressed to drag folders, closing
User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 SeaMonkey/2.15a1
Build identifier: 20120921003032
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Whiteboard: [2012 Fall Equinox]
You need to log in before you can comment on or make changes to this bug.