Closed Bug 133601 Opened 23 years ago Closed 23 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: 23 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: