Closed Bug 71768 Opened 24 years ago Closed 23 years ago

sidebar bookmark folder icon and twisty have wrong click behavior


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



(Not tracked)



(Reporter: gilles+mozilla, Assigned: dead)



(Whiteboard: fix in hand, waiting on branch checkin)


(2 files)

2001031204 trunk win98

Single-click and double click in bookmark sidebar are swapped :

double click on triangle -> opens/closes folder
single click on triangle -> nothing

single-click on bookmark -> opens the bookmark in windows
*** Bug 71789 has been marked as a duplicate of this bug. ***
I see this on linux too, and the dup is Mac - OS: All.
Hardware: PC → All
It fixes double click problem but now you can accidentally active Folder Rename
in some situations. I don't have time to fix that for now.
OS: Windows 98 → All
This doesn't fix the single/double clicking issue for opening folders, it's
still reversed. The history panel behaves correctly, couldn't some code be
stolen from it (shouldn't they use the same code for the tree?).
Build 2001031308 on Linux - bug is still there.
fwiw: clicking once on a twisty in sidebar bookmarks, this displays in console:
JavaScript error: 
chrome://communicator/content/bookmarks/bookmarksTree.js line 405:
gSelectionTracker.currentItem has no properties
(linux 2001-031321)
yes, there also seems to be initialization problem.
*** Bug 71929 has been marked as a duplicate of this bug. ***
*** Bug 71789 has been marked as a duplicate of this bug. ***
*** Bug 73386 has been marked as a duplicate of this bug. ***
*** Bug 74687 has been marked as a duplicate of this bug. ***
*** Bug 75692 has been marked as a duplicate of this bug. ***
Single click on a bookmark in the sidebar should load the URL. Usability tests
showed that is what people expect.
Not my definition of usable bookmarks, but that's not the bug here. The point is
that bookmark-folder decorative icons behave differently.

In the sidebar, clicking on the small arrow doens't do anything. In the "Manage
Bookmarks" window it opens the folder.

Again in the sidebar, clicking on the folder icon opens the folder, in the
"Manage Bookmarks" window it does nothing.

Same holds for double-clicking in them.
Let me add one more point on the usability matter.

I want to delete a bookmark from the sidebar pane. I left click on it to open
the context-menu. I get the menu, but I also get to visit the page I want to
delete from the bookmarks.

Or is this maybe another bug? That right-clicks shouldn't "visit" bookmarks?
yup, sounds like a separate bug to me. 
From a month-old comment from bug 76420 and since single-click on a bookmark is
the rule, i'm changing summary.
Summary: Single-click and double-click swapped in bookmark sidebar → double-click on twisty expands bookmark folder
*** Bug 82509 has been marked as a duplicate of this bug. ***
Nominating nsbeta1.
Keywords: nsbeta1
So what is this bug about now?  What are people expecting to happen when
double-clicking a folder? 
Peter, I think what people expect in the bookmarks sidebar tab is the same
behavior as everywhere else in the app, including the manage bookmarks window. 
The behavior is swapped currently:

In sidebar (incorrect behavior):

Single click on folder to open/close folder
Double click to open/close with twisty

In bookmarks window (correct behavior):

Double click on folder to open/close folder
Single click to open/close with twisty

This is a usability issue we have to fix for rtm.
exactly what todd said. updating summary. (that's really two problems (twisty,
folder icon) but I feel their resolutions will track together and can be just
the one bug)
Summary: double-click on twisty expands bookmark folder → sidebar bookmark folder icon and twisty have wrong click behavior
A suggestion: Why don't you just get rid of the 'twisty'?

This would give a extra character and a half space to the very 
precious screen 'real estate' of the side bar and let me see just
that little bit extra of what that poorly titled html document was
that I was far to lazy to retitle...

Also bookmarks in a submenu are indented THREE times, surely 
2.5 is enough!
nav triage: frequency high (lots of users affected), severity low. 
P2, mozilla0.9.2. nsbeta1+. 
Keywords: nsbeta1nsbeta1+
Priority: -- → P2
Target Milestone: --- → mozilla0.9.2
Weird, my code seems to be doing the right thing. I'm not really sure what else
I can do other than set the open attribute (which is what I'm doing, and I'm
being ignored by the old tree widget.) At any rate, it seems this bug will go
away when the bookmarks trees are converted to rdfliner. 

Setting dependencies, clearing nsbeta1+. 
Depends on: 73508
Keywords: nsbeta1+
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Target Milestone: mozilla0.9.3 → mozilla1.0
I would really like high priority given to see this fixed. It makes the product 
look kaputt. It is a strong usability and consistency issue, especially since 
it seems to affect only bookmarks in the sidebar. I think it has all the 
qualities of being a stopper.
renominating - although i don't know what that means now.
Keywords: nsbeta1
Hmm.  I can't even see my bookmarks in the sidebar today, but I'd sure like to
see this as at least a 'limbo' candidate.  Ben, if there is anything my team can
do to help you out so that this can get fixed, please let me know.
nav triage team:

Marking nsbeta1+ and mozilla0.9.3, Ben don't sweep this under the rug just yet 
until we can hopefully get more eyeballs looking into this.
Keywords: nsbeta1nsbeta1+
Target Milestone: mozilla1.0 → mozilla0.9.3
-> blake
Assignee: ben → blaker
Assignee: blaker → blake
Attached patch patchSplinter Review
Whiteboard: fix in hand
I tested the patch on linux, it works fine. I noticed one strange behavior, but
it's not worth holding the checkin of this fix:
If you right-click on the arrow to expand/collapse a folder, the context menu
will come up, but the open action will also be performed. That means that, if
the folder was closed, right-clicking on its arrow will
1) Expand the folder
2) Produce a context menu with the "Expand" command in it.
Click on Expand in this context menu will collapse the folder, thus undoing the
As I said this is not serious enough imho to hold the checkin for this patch.
Fix checked in on trunk.
Whiteboard: fix in hand → fix in hand, waiting on branch checkin
Vishy, I think we should mark this nsBranch.
*** Bug 88348 has been marked as a duplicate of this bug. ***
Vishy, nsBranch?
*** Bug 88859 has been marked as a duplicate of this bug. ***
*** Bug 86579 has been marked as a duplicate of this bug. ***
Marking mostfreq at 9 bugs. One early, but the dynamics is right (3 dups in a week)
Keywords: mostfreq
This was supposed to be PDT+. I forgot about it.  Claudius, can you verify this 
on the trunk please?
Keywords: nsBranch
-> blakes evil Netscape twin :-)
Assignee: blake → blaker
Right clicking should have NO effect on folder open/close behaviour (currently,
it does).

I actually prefered the *single click on folder to open folder* behaviour. Could
we have this back please?
On the trunk we are 'okay to go'. That is to say the correct behavior of one-click to activate the
twisty and two clicks for the folder icon is currently correctly implemented.

I'm not pleased that right-clicking still activates these items (as well as the context menu) but
at least the context items are correctly sensitive and the expand/collapse doesn't get out of sync.
While I'm at it I still don't like that 1-click surfs to a bookmark, but I digress:

This bug is VERIFIED Fixed for _trunk_ builds 20010710 and I support checking into the branch.
Okay, so Vishy, where do we go from here?

Note that if only one more bookmarks fix is allowed into RTM, I'd rather see it 
be 85328, because that fixes tons of drag and drop issues with a small patch.  
So we may want to focus our energy on that, since PDT is getting strict about 
out of Branch consideration now. 
Closed: 23 years ago
Keywords: nsBranch
Resolution: --- → FIXED
This may need to be reopened.  In build 2001071604 on NT4, the single click on
the twisty works on the top level, but still requires a double-click on the
second level(this is especially annoying when going through history!).

WFM with 2001072003 WindowsME

Michael Baffioni: Are you sure you are not using a branch build? (downloaded
from a directory ending with -0.9.2 and showing Mozilla 0.9.2 in the about: window)
*** Bug 92000 has been marked as a duplicate of this bug. ***
No longer depends on: 97345
mass-verifying claudius' Fixed bugs which haven't changed since 2001.12.31.

if you think this particular bug is not fixed, please make sure of the following
before reopening:

a. retest with a *recent* trunk build.
b. query bugzilla to see if there's an existing, open bug (new, reopened,
assigned) that covers your issue.
c. if this does need to be reopened, make sure there are specific steps to
reproduce (unless already provided and up-to-date).


[set your search string in mail to "AmbassadorKoshNaranek" to filter out these
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.