Closed Bug 92380 Opened 23 years ago Closed 22 years ago

Context menu in Personal Toolbar incorrect when Sidebar items selected

Categories

(SeaMonkey :: Bookmarks & History, defect, P2)

Product:
SeaMonkey
Component:
Bookmarks & History
Platform:
x86
All
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.2beta

People

(Reporter: cplyon, Assigned: p_ch)

References

Details

(Keywords: dataloss, Whiteboard: [adt2])

Attachments

(1 file, 3 obsolete files)

Patch v1.3
1.58 KB, patch
p_ch
: review+
bzbarsky
: superreview+
Details | Diff | Splinter Review 
Using build 2001072503 on Win2K

Steps to Reproduce:
1-Make sure there is a bookmark in the Personal Toolbar
2-Open the Bookmark Sidebar Tab
3-Select in the sidebar (and make sure focus stays on):
  a)folder
  b)separator
4-Right click on a bookmark on the Personal Toolbar and select Properties (for 
example)

Expected Results:
The properties dialog should show the properties of the bookmark on the 
personal toolbar.

Actual Results:
a) the properties for the folder are displayed
b) nothing

It appears that when a non-bookmark is selected and has focus in the sidebar, 
it takes control of the context menu.  This effects all the context menu items 
(including Delete which results in dataloss).  

Could be related to bug 91899.
Adding dataloss keywords because of the Delete and Cut menu items.
Keywords: dataloss
nav triage team:

Marking p2 and mozilla0.9.4
Priority: -- → P2
Target Milestone: --- → mozilla0.9.4
nav triage team:

Forgot the nsbeta1+
Keywords: nsbeta1+
oy. the grand old controller screwery lives on.
Status: NEW → ASSIGNED
Ben, can you update the bug with an eta, analysis etc? thanks, Vishy
nav triage team:

Although nice to fix, not critical for mozilla0.9.4, pushing out to mozilla0.9.5
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Mass-moving lower-priority 0.9.5 bugs off to 0.9.6 to make way for remaining
0.9.4/eMojo bugs, and MachV planning, performance and feature work. If you
disagree with any of these targets, please let me know.
Target Milestone: mozilla0.9.5 → mozilla0.9.6
*** Bug 101286 has been marked as a duplicate of this bug. ***
*** Bug 104556 has been marked as a duplicate of this bug. ***
Paul Chen is now taking Bookmarks bugs. For your convenience, you can filter 
email notifications caused by this by searching for 'ilikegoats'.
Assignee: ben → pchen
Status: ASSIGNED → NEW
mass moving mozilla0.9.6 bugs to mozilla0.9.7
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Pushing out to mozilla0.9.8
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.7 → mozilla0.9.8
*** Bug 117880 has been marked as a duplicate of this bug. ***
Changing OS to All based on duplicates.
OS: Windows 2000 → All
mass reassign of pchen bookmark bugs to ben
Assignee: pchen → ben
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Target Milestone: mozilla0.9.9 → mozilla1.1
*** Bug 122911 has been marked as a duplicate of this bug. ***
i deleted my whole personal toolbar folder yesterday, when i thought i was just
deleting a bookmark on personal toolbar. Shouldn't this be a 1.0 bug at worst?
*** Bug 131963 has been marked as a duplicate of this bug. ***
Insight from duped bug 131963:

Summary: "Deleting a bookmark in Personal Toolbar can delete entire bookmark
directories in Sidebar"

This seems to happen if the user had previously selected a BM directory in the
sidebar and then rightclicks on a BM in the Personal Toolbar and selects delete.
The delete will actually be performed on the previously selected Sidebar item. 

I can't even begin to describe how devastating this bug is. Imagine wanting to
delete *one* bookmark and end up deleting one of you most deeply nested bookmark
directories. :( :( :(

This should clearly be a *critical* bug with keywords: dataloss, mozilla1.0,
nsbeta1, nsbranch, nsCatFood

[rant] This bug has been pushed out enough now :( [/rant]
Keywords: nsbeta1
Severity: normal → critical
nsbeta1+ per Nav triage team, Nav2, ->1.0
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [nav2]
Target Milestone: mozilla1.1alpha → mozilla1.0
At least on the 2002033008 build in MacOS X this behavior happens regardless of
what is selected in the sidebar.  Seperator, Folder, Bookmark selected in the
sidebar causes Properties, Delete, or Rename in Contextual Menus of the Personal
Toolbar to reflect the Sidebar selection not the Personal Toolbar selection...

Also, New Folder contextual menu in Personal Toolbar creates a Folder in the
selected Sidebar section, not in the Personal Toolbar folder.

Bill
<billvinson@nc.rr.com>
Please update this bug with an [adt1] - [adt3] impact rating (or take it off the
list if it doesn't even rate adt3.)  Thanks!
Whiteboard: [nav2] → [adt2]
converting nav2->adt2
*** Bug 137028 has been marked as a duplicate of this bug. ***
nsbeta1- per Nav triage team
Keywords: nsbeta1+ → nsbeta1-
Whiteboard: [adt2]
Target Milestone: mozilla1.0 → mozilla1.1alpha
*** Bug 138044 has been marked as a duplicate of this bug. ***
*** Bug 141701 has been marked as a duplicate of this bug. ***
*** Bug 144030 has been marked as a duplicate of this bug. ***
*** Bug 150409 has been marked as a duplicate of this bug. ***
*** Bug 150578 has been marked as a duplicate of this bug. ***
*** Bug 155365 has been marked as a duplicate of this bug. ***
This really is a terrible bug.  I just deleted a bunch of my bookmarks without
realizing it, and now I have no way of knowing what I just deleted, and no way
of getting them back.  I expect this in a nightly I'm experimenting with, but
not in 1.0.

If nobody can figure out a fix for this bug, the context menu for the Personal
Toolbar should be disabled until a fix is checked in.

renominating nsbeta1 this fix is a great one to pick up and is starting to pile
up a lot of dupes.
Keywords: nsbeta1- → nsbeta1
Nav triage team: nsbeta1+/adt2
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt2]
taking
Assignee: ben → pierrechanial
Status: ASSIGNED → NEW
Attached patch Patch v1.0 (obsolete) — — Splinter Review 
The command dispatcher was confused.
Patch focusing the personal toolbar before the creation of the cm.
After that the command is executed, I sets the focus to the content area. It
would be better to sets it back where it was but I have no idea how to do it
easily.
r/sr needed.
Status: NEW → ASSIGNED
Comment on attachment 93624 [details] [diff] [review]
Patch v1.0

I like the patch, but I say don't overload the focus ident since it's
implemented by many other things and if this specific caller ever gets removed,
someone may not realize they need to also remove it from the .js file as well. 
I would call your function doFocus() or something similar....
Attached patch Patch v1.1 (obsolete) — — Splinter Review 
I agree, this patch now use doFocus
Attachment #93624 - Attachment is obsolete: true
Comment on attachment 93836 [details] [diff] [review]
Patch v1.1

r=caillon if you use |content| instead of |_content|
Attachment #93836 - Flags: review+
Attached patch Patch v1.2 (obsolete) — — Splinter Review 
Et voila!
Attachment #93836 - Attachment is obsolete: true
Comment on attachment 93871 [details] [diff] [review]
Patch v1.2

carrying caillon's review
Attachment #93871 - Flags: review+
Attached patch Patch v1.3 — — Splinter Review 
Added a comment, per Bryner request
Attachment #93871 - Attachment is obsolete: true
Comment on attachment 94408 [details] [diff] [review]
Patch v1.3

carrying caillon's review
Attachment #94408 - Flags: review+
*** Bug 161942 has been marked as a duplicate of this bug. ***
This is an annoying bug with a small, straightforward patch with a very small
chance of regression.  Adding patch keyword, nominating for 1.2, and bumping
Target Milestone (since this patch didn't make 1.1, the previous target).
Keywords: mozilla1.2, patch
Target Milestone: mozilla1.1alpha → mozilla1.2beta
*** Bug 170385 has been marked as a duplicate of this bug. ***
Comment on attachment 94408 [details] [diff] [review]
Patch v1.3

sr=bzbarsky
Attachment #94408 - Flags: superreview+
*** Bug 178799 has been marked as a duplicate of this bug. ***
Adding approval keyword.

Let's get this thing checked in already!
Keywords: approval
I already requested drivers' approval for 1.2
Bah...
I'll check in the patch this week end for 1.3a
fixed!
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
*** Bug 185859 has been marked as a duplicate of this bug. ***
vrfy'd fixed on win2k and linux rh8.0 with 2003.02.19 comm trunk.
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: