251910 - No hover highlighting (i.e. mouse-tracking) in Bookmarks/History sidebar

Status: VERIFIED FIXED

(Firefox :: Bookmarks & History, defect)

Description

[Oomingmak]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040707 Firefox/0.9.2 StumbleUpon/1.994
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040707 Firefox

Although the issue of single versus double clicking has been raised in relation
to the History and Bookmark sidebars
http://bugzilla.mozilla.org/show_bug.cgi?id=171106   the issue of hover
highlighting has not been mentioned or dealt with. 

The History bar ALREADY has single-click activation implemented, so therefore it
should have hover highlighting and selection as well.

At the moment it is impossible to select more than one bookmark item, because
you have to click to select (due to there being no mouse-over selection). But
this does not work because clicking causes the bookmark to launch immediately.
Even if you hold down control or shift (the standard ways to multiple select)
the book marks still launch as soon as you click on them.



Reproducible: Always
Steps to Reproduce:
1. Open History Side bar
2. Attempt to select more than one bookmark (by holding down the cntrl key and
clicking on the files one after another).


Actual Results:  
The bookmarks that you clicked on are not selected, they just launch into the
browser window as soon as they are clicked. You still end up with only 1 item
selected.

Expected Results:  
The bookmark should changed colour on mouse-over and become selected shorty
after (if the mouse stays hovered over it). That way, you can hold down the
control key and hover over several bookmarks (selecting each one in turn). The
same should apply with the shift key (for selecting the start and end point of a
selection range). Once selected, you are then free to click (to launch all of
them) or drag (to move them to a new folder or drag into the browser window).

At the moment, you would have to do this one bookmark at a time.

I was going to post this as part of a wider general comment about single /
double clicking and repecting the users settings in their Operating System.

Programs like WinZip (on Windows) reads the Registry to see what the user has
chosen to use in the OS (i.e. single or double click to launch items). WinZip
then behaves in exactly the same manner (even down to matching the same hover
highlight colour and underlining, if it has been selected). 

This makes for a seamless experience with the User's OS and much better
integration. It also means one type of clicking is not being forced on users who
do not want it.

I would suggest that this method be adopted througout Firefox if at all possible
(as this would make the Firefox interface consistent). At the moment single /
double clicking is being implemented differently in different parts of the
program (e.g. Histoty versus Bookmark sidebars). 

Finally, it is importnat to remember that single-click launch must ALWAYS be
accompanied by hover highlighting and selection (otherwise there is no way to
select anything!).

Comment 1

[Oomingmak]

From Microsoft Developer Network (MSDN) User Interface Design Guide

"If the user selects single-click activation, then use hover (pointer held for
time-out) for click operations and click for double-click operations".

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwue/html/appxa.asp

Comment 2

[Oomingmak]

It should also be noted that even with hover selection activated, files can
STILL be clicked on to be selected when the modifier keys 'ctrl' or 'shift' are
held down (this is exactly the same method that double-click users always have
use to select multiple files).

So the selection process need not involve 'hovering' over each file if the user
does not wish to select files in that way. And by having some kind of visual
feedback on mouseover, it makes the behaviour of bookmarks more consistent with
items such as toolbar buttons, tab bar close button, menus etc. (all of which
respond visually to mouse over).

Comment 3

[Matt]

This is most annoying.

I agree the single-click launch history item is a good thing, but losing the
ability to select multiple items is terrible.

Please have both.

Comment 4

[Brendan Eich [:brendan]]

So we either need link styling for the items in history, or we need to revert to
the double-clickable behavior.  The way things are now is confusing.  Selection
should still work, ideally.

/be

Comment 5

[Blake Ross]

-> mconnor

Comment 6

[Mike Connor [:mconnor]]

patch is on linux, when I have time, I'll post it

its basically the patch at http://www.steelgryphon.com/stuff/linkTree/ with the
default blue link color, after a short talk with vlad.

however, if kevin/steven have better styling ideas (nothing that cursor: foo
doesn't work right on pseudo-elements, and neither does :hover) then by all
means do what feels right with this patch.

Comment 7

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

mconnor is away briefly, mconnor if you come back and get your stuff in order,
re-block. 

Comment 8

[chris hofmann]

lets get the styling patch in or revert back.

Comment 9

[Kevin Gerich]

I applied mconnor's patch plus a blue color to my local build and it works fine.
Has the decision been made to go with the link styling? I'd be happy to check
this in.

Just to be clear, the patch styles the tree cell text in the bookmark and
history sidebar blue and underlined. As mconnor said, the cursor does not change
to a pointer when the mouse is over it.

Comment 10

[chris hofmann]

I wonder if 
 
   cursor: pointer
 
can be added to the style rule to get the right hover effect?

Comment 11

[chris hofmann]

also wondering about the possibility of a "tree stylesheet" that all themes
could share...  maybe that part comes later

Comment 12

[Kevin Gerich]

Sorry, that's what I meant. cursor: pointer doesn't work doesn't seem to work
inside the tree.

Comment 13

[chris hofmann]

is https://bugzilla.mozilla.org/show_bug.cgi?id=217472 the orginal bug where
this feature went in?

Comment 14

[Brendan Eich [:brendan]]

Without link hovering, how can you tell what the URL is?  Does Copy Link
Location work in the context menu?

Blake argued to aviary that we should go back to double-clicking because the
patch to make single-click history tree elements work correctly wouldn't make
1.0.  The patch on mconnor's site does make single-clicking work, and with the
change Kevin made, it even gets the color right, as well as underlining.  But
cursor, context menu, URL discoverability are all missing, along with tree-like
multiple selection.

In spite of the good efforts at the last minute, history sidebar tree items are
not working right yet.  We have to have some consistent standard of quality.  If
we can't get the UI to follow the sane, normal rules documented for links, and
by MSDN for "single-click activation", etc., then we should revert to double
click navigation.

Cc'ing dbaron in case he can suggest a way to get cursor: pointer, the Copy Link
Location context menu item (and any other related items standard for hoving over
links), and the URI tooltip when hovering to work.

/be

Comment 15

[Brendan Eich [:brendan]]

Blake points out that I'm mixing up things (becuase I'm remembering SeaMonkey or
IE).  We haven't had URLs in history item text for a while in Firefox.  And Copy
Link Location is there in the context menu.  So what this boils down to is:

- no cursor: pointer;
- no URL tooltip when hovering;
- no way to select tree items.

I bet dbaron could help us fix the first two easily -- I'm happy to lose that
bet. I'd still like to get selection, too, but it's not a 1.0 blocker.

/be

Comment 16

[Mike Connor [:mconnor]]

Brendan, cursor: pointer doesn't work because the fix for bug 221619 went in for
1.8a instead of 1.7b.  We'd have to take a hefty patch, or try to come up with a
safe, last-minute patch to backport just the cursor: support.  Not something I
think it quite critical, personally.

URL tooltips to my knowledge have not been in for a long time, and I don't think
I've even seen a bug reported on them.  I certainly haven't seen any feedback
elsewhere about this not being there.  I think that its a good idea, but its not
something that we should worry about at this massively late stage.

If you want an example of how badly single-click activation and multiple
selection work together, just look at the seamonkey sidebar.  Like I've said,
figuring out a Mac-style way of tree selection would be good, but that's
anything but low-risk at this point.  I know how to do it already, but it just
isn't something that should go in without a longer-term bit of testing.

There still isn't a compelling argument right now for doing anything but styling
things a little more link-like.  Bigger monkeying between PR and RC is really
just a matter of Too Many Cooks Too Late.  I don't believe double-click adds
anything other than "manager-like" functionality to the sidebars, which we're
moving AWAY from, since sidebars are largely unsuited for managment-like actions.

Comment 17

[Brendan Eich [:brendan]]

mconnor: obviously we wouldn't take any fix for cursor that wasn't small and
safe, etc.  Claiming it's too late is ironic, given the patch for this bug
(still not attached) hasn't landed.  If we can take a small patch for link
styling, we can take an equally small and low-risk patch (if it exists) for cursor.

I'm not a cook, just a hungry customer.  I don't think incoherent UI is good,
even if it's the least evil or the best we can do at this point.  Standards of
judging quality of implementation shouldn't slip even if we don't fix this bug
for 1.0 -- we should do better next time, and all that.

/be

Comment 18

[Mike Connor [:mconnor]]

the patch for this is stone simple, and just adds a property to a couple trees,
and some CSS.  To add cursor support for pseudo-elements in trees is mucking in
Gecko.  They're not even close in terms of complexity.

Nothing in the UI is incoherent, the only actual complaint I've heard is the
lack of multi-selection.  But I suppose that's subjective.

Comment 19

[chris hofmann]

ok, it sounds like we should get this patch in soon.  who can do that?

Comment 20

[Kevin Gerich]

Attachment: mconnor's style patch + blue links

Comment 21

[Kevin Gerich]

patch checked in on branch

Comment 22

[Kevin Gerich]

...and trunk too

Comment 23

[Steffen Wilberg]

So why do we style items in the sidebar like links if we can't get
cursor:pointer to work? Hovering over the items feels broken because they look
like links, but the cursor doesn't change.

I don't like this. Bookmarks aren't links. What about the bookmarks toolbar? The
icons there have single-click activation as well. That doesn't mean we have to
style them like links, does it? But why should bookmarks look different in the
bookmarks toolbar and the sidebar?

Comment 24

[amano]

I think Steffen is 100% right. Bookmarks are no links. They are... Bookmarks.
Simple as it is.

For the sake of Internet Explorer compliance... Back this out.

Comment 25

[Daniel Ross]

Forget Internet Explorer compliance, somebody think of the retinae. Having an
entire sidebar full of blue underlined "links" is really atrociously ugly, and
is actually causing me eye strain. PLEASE back these changes out until you're
ready to only have the link-style decoration on hover. The current 'solution' is
far worse than the problem.

Comment 26

[Raanan Barzel]

The choice of underlined characters is needlessly inconsistent with the
Bookmarks menu, which is already a single click.

The choice of blue characters is unhappy: on Windows classic theme, click and
hold a bookmark in the sidebar makes the bookmark unreadable!

Comment 27

[Blake Ross]

The more I use this and read others' comments about it, the more I agree that
this just isn't the right way to go. There are too many problems with this
styling that we can't fix right now. It's more than just a polish issue: the
sidebars really are less usable with everything underlined like that. IE solves
this by only underlining on hover. We can't do that.

Asa also reports that history management has gotten very noticeably slower since
the styling change went in, which is believable. Let's back out the CSS patch
for 1.0 (leave it single click) and tackle it again in 1.5 when our Gecko
support is better.

Comment 28

[Kevin Gerich]

OK .. patch backed out

Comment 29

[amano]

Kevin, you already did? I cannot see a checkin onto the branch in the aviary
tinderbox. The last checkin was from 2004-10-17 15:05(lighter background color
for link styles).

Comment 30

[Kevin Gerich]

Sorry, I jumped the gun with my comment :) it's really backed out now

Comment 31

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

Attachment: behavioral fixes [checked in branch and trunk]

- make history folders open on single click like Bookmarks
- allow use of modifier keys to perform multiple/ranged select

Comment 32

[Brendan Eich [:brendan]]

Comment on attachment 162430 [details] [diff] [review]
behavioral fixes [checked in branch and trunk]

Ben: I love you, man! ;-)

/be

Comment 33

[Met - Martin Hassman]

>So why do we style items in the sidebar like links

Maybe I am wrong, but bug this is not about Firefox *will underline* bookmarks
and history in the sidebar, but Firefox *should be able to underline* them. It
depends on the theme author (or I am completely wrong).

If the theme authors are able to do (IE-theme) it, or admins can modify it by
editing userChrome.css (for simpler users transition) it is other ten points for
Firefox.

(Last week I he tried this because of complain of some czech users, but I was
not able to style it. So I am very happy for this bug.)

Comment 34

[Daniel Ross]

You're correct that that is what this bug is about. However, the comment you're
responding to referred to a partial patch for this bug which did indeed cause
bookmarks to be link-formatted at all times. It was checked in two days ago and
immediately decried as a major misfeature as soon as it began to show up in
builds. It has since been backed out, which is why those comments may seem
nonsensical to you.

Comment 35

[Bumbleboo]

It seems to me that much of this debate is confused by focussing on the wrong
kind of "messages" that controls are handling.

For instance, an application programmer using a button would not be expected to
deal with primary-mouse-button-down and primary-mouse-button-up messages, but
would expect the control to translate that into something more meaningful for
the functional context of the control -- in this case a "click" message (or,
more accurately, a "button-push" message).  Ie messages related to user intent,
not to actions performed on the input device (mouse).

In the case of the history and bookmarks sidebars, the type of messages that
should be handled are "select" and "activate" (or launch).  How single-click,
hover, double-click etc messages are translated by the control should be based
on operating system settings (so "select" is "hover" on a single-click system,
and "select" is "click" on a double-click system).

(In this context, "hover" means the action of leaving the mouse pointer static
over a control for a period of time to select something -- there are of course
additional mouse-over messages, such as the instantaneous one used to provide
visual feedback aka hover-highlight, and the delayed one used for showing tooltips).

Fundamentally the application programmer should not be handling "click"
messages, but should be handling messages appropriate to user intent.

This is essentially what Oomingmak is saying in <a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=217472#c43">Bug 217472,
Comment #43</a>.

I don't know enough about how firefox is built to know what the underlying
control used in the sidebar is; if it doesn't currently handle "select" and
"activate" messages, then it should -- whether this means a change to the
mozilla framework, or means that firefox should develop a custom control of its
own to handle this message translation I don't know.  

The firefox developer should be dealing with "select" and "activate".  Not
dealing with "click", "double-click" and "hover".

Comment 36

[Greg Campbell]

Regardless of the wisdom of comment 35, if the History and Bookmarks sidebar are
going to act like lists of links (which is totally acceptable for a web
browser), the links should act like links: take the appropriate cursor on hover
(hand). "Contemporary" link style seems to include some kind of style change on
hover (change of color, addition of underline, etc.).

Having the links permanently underlined (which was thankfully backed out) is
generally considered (at best) somewhat more difficult to read or (at worst)
just plain ugly.

Comment 37

[Mike Connor [:mconnor]]

Since we have more styling ability for trees, I'll poke this a bit and see if we
can clean it up more.  At the least, cursor: hand for when you're on the link
that'll open, and pointer for where it'll do selection, but hopefully a hover
underline effect is possible (its been a while, but it should work, iirc).

Comment 38

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #37)
> At the least, cursor: hand for when you're on the link that'll open,

I think you mean 'cursor: pointer'...

> and pointer for where it'll do selection

... and 'cursor: default'.

Comment 39

[Mike Connor [:mconnor]]

Yeah, that'd be what I meant.  Dunno why I remembered the IE-ism, other than
calling the hand cursor "pointer" has always conflicted with my mental
definition of a mouse pointer.

Comment 40

[Steffen Wilberg]

Comment on attachment 162253 [details] [diff] [review]
mconnor's style patch + blue links

Obsoleting the "blue links" patch, which has been backed out.

Comment 41

[Mike Connor [:mconnor]]

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

Comment 42

[Brian Polidoro]

Am I correct in assuming that this bug would probably depend on bug 145320 to be
fixed in order to fix this bug properly? 

Comment 43

[Dão Gottwald [:dao]]

Attachment: underline & cursor:pointer for winstripe (checked in)

Comment 44

[Dão Gottwald [:dao]]

Comment on attachment 283539 [details] [diff] [review]
underline & cursor:pointer for winstripe (checked in)

Is this wanted for Mac, too?

Comment 45

[(not reading, please use [e-mail] instead)]

Comment on attachment 283539 [details] [diff] [review]
underline & cursor:pointer for winstripe (checked in)

r=sspitzer, assuming this doesn't hurt the peformance of the places organizer.

see
http://developer.mozilla.org/en/docs/Writing_Efficient_CSS#Tag-categorized_rules_should_never_contain_a_child_selector.21

Also, I think you'll need beltzner's ui-r for this change.

Comment 46

[Dão Gottwald [:dao]]

(In reply to comment #45)
> (From update of attachment 283539 [details] [diff] [review])
> r=sspitzer, assuming this doesn't hurt the peformance of the places organizer.
> 
> see
> http://developer.mozilla.org/en/docs/Writing_Efficient_CSS#Tag-categorized_rules_should_never_contain_a_child_selector.21

The treechildren that I want or the corresponding trees don't have distinctive class names, so I start with "page" to affect sidebars only.

> Also, I think you'll need beltzner's ui-r for this change.

The patch implements what mconnor wrote in comment 37, so I don't think an explicit ui-review is needed.

Comment 47

[Mike Connor [:mconnor]]

Comment on attachment 283539 [details] [diff] [review]
underline & cursor:pointer for winstripe (checked in)

a=mconnor, this is something worth trying, and probably worth doing on Mac if initial feedback is good.  We really should get a Themes component or three

Comment 48

[Dão Gottwald [:dao]]

(In reply to comment #47)
> (From update of attachment 283539 [details] [diff] [review])
> a=mconnor, this is something worth trying, and probably worth doing on Mac if
> initial feedback is good.

In that case, I'll also have to add the placesTree class to the history tree. I realized that it's missing there, so the current patch works for the bookmarks sidebar only. Furthermore, separators need to be excluded from the cursor rule.

Comment 49

[Reed Loden [:reed]]

Checking in browser/themes/winstripe/browser/places/places.css;
/cvsroot/mozilla/browser/themes/winstripe/browser/places/places.css,v  <--  places.css
new revision: 1.17; previous revision: 1.16
done

Comment 50

[Dão Gottwald [:dao]]

I'm not yet done here (comment 48), but thanks for the check-in.

Comment 51

[Dão Gottwald [:dao]]

Attachment: follow-up patch

what this does is:
- add the styling to the Mac theme
- use better selectors as suggested by Seth
- exclude separators from the styling
- make the appearance of the history and bookmarks sidebars consistent, which is only remotely related to this bug

Comment 52

[(not reading, please use [e-mail] instead)]

Comment on attachment 284549 [details] [diff] [review]
follow-up patch

r=sspitzer

Comment 53

[Damon Sicore (:damons)]

Comment on attachment 283539 [details] [diff] [review]
underline & cursor:pointer for winstripe (checked in)

Resetting approval flags on bugs that have not been checked in by Oct 22, 11:59PM PDT.  Please re-request approval if needed.

Comment 54

[Reed Loden [:reed]]

Comment on attachment 283539 [details] [diff] [review]
underline & cursor:pointer for winstripe (checked in)

Landed as rev 1.17 of places.css on 2007-10-11 14:38.

Comment 55

[Damon Sicore (:damons)]

Comment on attachment 283539 [details] [diff] [review]
underline & cursor:pointer for winstripe (checked in)

Re-approving as this bug was already checked in.

Comment 56

[Reed Loden [:reed]]

Checking in browser/components/places/content/bookmarksPanel.xul;
/cvsroot/mozilla/browser/components/places/content/bookmarksPanel.xul,v  <--  bookmarksPanel.xul
new revision: 1.7; previous revision: 1.6
done
Checking in browser/components/places/content/history-panel.xul;
/cvsroot/mozilla/browser/components/places/content/history-panel.xul,v  <--  history-panel.xul
new revision: 1.12; previous revision: 1.11
done
Checking in browser/themes/pinstripe/browser/places/places.css;
/cvsroot/mozilla/browser/themes/pinstripe/browser/places/places.css,v  <--  places.css
new revision: 1.16; previous revision: 1.15
done
Checking in browser/themes/winstripe/browser/places/places.css;
/cvsroot/mozilla/browser/themes/winstripe/browser/places/places.css,v  <--  places.css
new revision: 1.18; previous revision: 1.17
done

Comment 57

[Tracy Walker [:tracy]]

verified with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2007122005 Minefield/3.0b3pre and the equivalent Mac build

Comment 58

[Gervase Markham [:gerv]]

Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body   contains   places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Gerv