71768 - sidebar bookmark folder icon and twisty have wrong click behavior

Status: VERIFIED FIXED

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

Description

[Gilles Durys]

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

Comment 1

[R.K.Aa.]

*** Bug 71789 has been marked as a duplicate of this bug. ***

Comment 2

[R.K.Aa.]

I see this on linux too, and the dup is Mac - OS: All.

Comment 3

[Asko Tontti]

Attachment: fix: restores double-click

Comment 4

[Asko Tontti]

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.

Comment 5

[Dagfinn I. Mannsåker]

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?).

Comment 6

[Vladimir Kondratiev]

Build 2001031308 on Linux - bug is still there.

Comment 7

[R.K.Aa.]

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)

Comment 8

[Asko Tontti]

yes, there also seems to be initialization problem.

Comment 9

[R.K.Aa.]

*** Bug 71929 has been marked as a duplicate of this bug. ***

Comment 10

[pbergsag]

*** Bug 71789 has been marked as a duplicate of this bug. ***

Comment 11

[Gilles Durys]

*** Bug 73386 has been marked as a duplicate of this bug. ***

Comment 12

[[e-mail]]

*** Bug 74687 has been marked as a duplicate of this bug. ***

Comment 13

[timeless]

*** Bug 75692 has been marked as a duplicate of this bug. ***

Comment 14

[Peter Trudelle]

Single click on a bookmark in the sidebar should load the URL. Usability tests
showed that is what people expect.

Comment 15

[Christos Cheretakis]

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.

Comment 16

[Christos Cheretakis]

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?

Comment 17

[Peter Trudelle]

yup, sounds like a separate bug to me. 

Comment 18

[Gilles Durys]

From a month-old comment from bug 76420 and since single-click on a bookmark is
the rule, i'm changing summary.

Comment 19

[Todd Pringle]

*** Bug 82509 has been marked as a duplicate of this bug. ***

Comment 20

[Todd Pringle]

Nominating nsbeta1.

Comment 21

[Peter Trudelle]

So what is this bug about now?  What are people expecting to happen when
double-clicking a folder? 

Comment 22

[Todd Pringle]

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.

Comment 23

[Claudius Gayle]

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)

Comment 24

[emmet]

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!

Comment 25

[Viswanath Ramachandran]

nav triage: frequency high (lots of users affected), severity low. 
P2, mozilla0.9.2. nsbeta1+. 

Comment 26

[Ben Goodger (use ben at mozilla dot org for email)]

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+. 

Comment 27

[Ben Goodger (use ben at mozilla dot org for email)]

out. 

Comment 28

[german]

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.

Comment 29

[Claudius Gayle]

renominating - although i don't know what that means now.

Comment 30

[Peter Trudelle]

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.

Comment 31

[Paul Chen]

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.

Comment 32

[Ben Goodger (use ben at mozilla dot org for email)]

-> blake

Comment 33

[Ben Goodger (use ben at mozilla dot org for email)]

waah

Comment 34

[Blake Ross]

Attachment: patch

Comment 35

[Ben Goodger (use ben at mozilla dot org for email)]

sr=[e-mail]

Comment 36

[Jason Kersey]

r=kerz

Comment 37

[Fabian Guisset]

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
action. 
As I said this is not serious enough imho to hold the checkin for this patch.

Comment 38

[Blake Ross]

Fix checked in on trunk.

Comment 39

[Todd Pringle]

Vishy, I think we should mark this nsBranch.

Comment 40

[Dave]

*** Bug 88348 has been marked as a duplicate of this bug. ***

Comment 41

[Blake Ross]

Vishy, nsBranch?

Comment 42

[Bradley Baetz (:bbaetz)]

*** Bug 88859 has been marked as a duplicate of this bug. ***

Comment 43

[timeless]

*** Bug 86579 has been marked as a duplicate of this bug. ***

Comment 44

[Jacek Piskozub]

Marking mostfreq at 9 bugs. One early, but the dynamics is right (3 dups in a week)

Comment 45

[Blake Ross]

This was supposed to be PDT+. I forgot about it.  Claudius, can you verify this 
on the trunk please?

Comment 46

[Viswanath Ramachandran]

-> blakes evil Netscape twin :-)

Comment 47

[Peter Lairo]

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?

Comment 48

[Claudius Gayle]

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.

Comment 49

[Blake Ross]

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 
plussing.

Comment 50

[Viswanath Ramachandran]

out of Branch consideration now. 

Comment 51

[Michael Baffoni]

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!).

Comment 52

[Jacek Piskozub]

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)

Comment 53

[Christopher Aillon (sabbatical, not receiving bugmail)]

*** Bug 92000 has been marked as a duplicate of this bug. ***

Comment 54

[sairuh (rarely reading bugmail)]

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).

thanks!

[set your search string in mail to "AmbassadorKoshNaranek" to filter out these
messages.]