Closed Bug 133601 Opened 22 years ago Closed 22 years ago

DND in a folder in personal toolbar: multiple folders can be open at once

Categories

(SeaMonkey :: Bookmarks & History, defect)

Product:
SeaMonkey
Component:
Bookmarks & History
Platform:
x86
Windows ME
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: p_ch, Assigned: p_ch)

References

Details

(Whiteboard: [adt2])

Attachments

(2 files)

Patch for the branch
1.36 KB, patch
p_ch
: review+
bugzilla
: superreview+
scc
: approval+
Details | Diff | Splinter Review
screenshot
219.09 KB, image/jpeg
Details 
windows build 2002 03 26 03

steps to reproduce:
1. manage your bookmarks so that you have at least two folders in the personal
toolbar
2. drag the proxy icon from the location bar and hover it on the first folder.
3. hover on the second bookmarks

Expected: first folder close and second one opens
Current: first and second folders are open

Comment: I don't know what should be the correct solution
1. close the folder menu when hovering outside of it.
2. close the folder after that another one has been opened.
Blocks: 133604
*** Bug 135611 has been marked as a duplicate of this bug. ***
Summary: DND in a folder in PT: multiple folders can be open at once → DND in a folder in personal toolbar: multiple folders can be open at once
*** Bug 136405 has been marked as a duplicate of this bug. ***
*** Bug 136607 has been marked as a duplicate of this bug. ***
(I'm not sure if the following scenario warrants its own bug, but...)

This bug is painfully visible if the user likes to drag links to the browser tab
bar.  When dragging a link on to a tab, the user is likely to over-shoot the tab
bar and briefly mouse over the PT.  If the PT contains many folders and
subfolders the UI ends up exploding with bookmark menus, covering the tab bar. 
The user must cancel the DnD operation, close each folder menu manually, and
then try again.

My PT is all folders, and this happens to me constantly.

Two possible solutions:
1. Open the PT folder only after the link has been dropped onto it (ala nn4)
2. Open the PT folder only after hovering for a period of time (ala springy
bookmark tree)

Personally, I prefer the way Navigator 4 did it.
nsbeta1+/adt2  This makes dragging worse than when the folders didn't pop up at
all.  I'd consider a third option: open the folder menu immediately on
mouseOver, but close it on mouseOut, or shortly thereafter, certainly before
opening a second folder menu.
Keywords: nsbeta1+
Whiteboard: [adt2]
Target Milestone: --- → mozilla1.0
*** Bug 134867 has been marked as a duplicate of this bug. ***
-> pierre, who has a fix for these issues. Thanks Pierre!
Assignee: blaker → pierrechanial
*** Bug 139366 has been marked as a duplicate of this bug. ***
Depends on: 139471
*** Bug 140111 has been marked as a duplicate of this bug. ***
*** Bug 141684 has been marked as a duplicate of this bug. ***
*** Bug 142844 has been marked as a duplicate of this bug. ***
*** Bug 143188 has been marked as a duplicate of this bug. ***
*** Bug 143278 has been marked as a duplicate of this bug. ***
Adding this to the "make rc3 not suck" list for Asa. It is possible to come
up with some kind of band-aid for now? Drivers doesn't want to take on the 
risk of an entire navigator.js rewrite for 1.0.
Blocks: 143200
No longer blocks: 143200
Blocks: 143200
here is the band aid for the branch.
But, please, review also bug 145350. I asked Pink, but I don't know if he's
around.
It looks like this will only fix the bookmarks menu staying open, not other
folders on the personal toolbar.  Will test on Win32 to see if this is the case.
Nevermind.  innermostBox contains the remaining PT folders.
Patch 84251 doesn't fix all issues for me on WinNT4. Steps to reproduce:

1.drag from proxy icon (urlbar) onto a menu on the personal toolbar
2.drag from this menu onto a 'normal' bookmark item.

Result, the last popup stays active! The rest, from popup to another popup,
seems to be Ok. So far so good, next step.
HJ: there are many many bug associated with DND inside PT toolbar folders, see
the dependency list of bug 139471.
The patch I have attached only fix this particular issue of this bug, namely
only one folder can be open at once.

I wonder whether this whole feature should be disabled or not for Moz1.0 like in
Linux. see bug 144191 for a recent regression.
erm bug 144195.
favicon, skin switching have been disabled, so why not this half implemented
feature?
Comment on attachment 84251 [details] [diff] [review]
Patch for the branch

r=bryner on IRC
Attachment #84251 - Flags: review+
Perhaps this is out of topic or asking too much, but, can the Personal Toolbar
menu behaviour be reviewed (bug 143762)?
Comment on attachment 84251 [details] [diff] [review]
Patch for the branch

a=scc (on behalf of drivers) for checkin to the mozilla1.0 branch

who's going to check this in?
Attachment #84251 - Flags: approval+
/cvsroot/mozilla/xpfe/browser/resources/content/navigatorDD.js,v  <--  
navigatorDD.js
new revision: 1.87.2.3; previous revision: 1.87.2.2
fix checked into 1.0.0 branch, sr waved by endico
Keywords: fixed1.0.0
Comment on attachment 84251 [details] [diff] [review]
Patch for the branch

Looks good. sr=blake
Attachment #84251 - Flags: superreview+
*** Bug 143967 has been marked as a duplicate of this bug. ***
This bug is fixed in 2002052306 M1.0 RC3
Yes, it has been fixed, but the new problem become it doesn't allow you to put
new URL to any subfolder in the main one.

1. I am using Mozilla 1.0 RC3, Windows 2000 Professional SP2.
2. Have a multiple folder bookmark dirctory under the Personal toolbar.
3. drug a URL into the last sub-folder of the main folder in the Personal toolbar.
4. It only opens the first sub-folder when you first time to find the sub-folder.
5. once you move on to the next one, it no longer be able to open any sub-folder
including the first one.

In the screenshot, you may be able to see, i can only drop it to the main folder.

Song Pan
Attached image screenshot — 

    
    

    
  
Song, the problem you are reporting was preexistent to the fix for the branch:
it is bug 144195

    
    

    
  
fixed by the checkin of bug 139471
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED

    
    

    
  
Already checked into the Moz 1.0.0 branch.  RS adt1.0.0+
Keywords: adt1.0.0+

    
    

    
  
I am a bit confused with this comment...
The patch in this bug has been checked into the branch and another patch that
solves the same problem has just been checked into the trunk. Please clarify if
it deals with mozilla, not the commencial trees.

    
    

    
  
looks fixed in the comm trunk --tested with 2003.02.19 on win2k.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: