Closed Bug 251910 Opened 21 years ago Closed 18 years ago

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

Categories

(Firefox :: Bookmarks & History, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 3 beta1

People

(Reporter: quis-quose, Assigned: dao)

References

Details

(Keywords: fixed-aviary1.0)

Attachments

(3 files, 1 obsolete file)

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!).
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
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).
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.
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
Flags: blocking-aviary1.0+
-> mconnor
Assignee: firefox → 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.
mconnor is away briefly, mconnor if you come back and get your stuff in order, re-block.
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
lets get the styling patch in or revert back.
Flags: blocking-aviary1.0- → blocking-aviary1.0+
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.
I wonder if cursor: pointer can be added to the style rule to get the right hover effect?
also wondering about the possibility of a "tree stylesheet" that all themes could share... maybe that part comes later
Whiteboard: partical patch
Sorry, that's what I meant. cursor: pointer doesn't work doesn't seem to work inside the tree.
is https://bugzilla.mozilla.org/show_bug.cgi?id=217472 the orginal bug where this feature went in?
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
Whiteboard: partical patch → partial patch
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
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.
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
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.
ok, it sounds like we should get this patch in soon. who can do that?
patch checked in on branch
...and trunk too
Keywords: fixed-aviary1.0
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?
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.
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.
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!
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.
OK .. patch backed out
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).
Sorry, I jumped the gun with my comment :) it's really backed out now
- make history folders open on single click like Bookmarks - allow use of modifier keys to perform multiple/ranged select
Comment on attachment 162430 [details] [diff] [review] behavioral fixes [checked in branch and trunk] Ben: I love you, man! ;-) /be
>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.)
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.
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".
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.
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).
Status: NEW → ASSIGNED
Target Milestone: --- → Firefox1.1
(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'.
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 on attachment 162253 [details] [diff] [review] mconnor's style patch + blue links Obsoleting the "blue links" patch, which has been backed out.
Attachment #162253 - Attachment is obsolete: true
Attachment #162430 - Attachment description: behavioral fixes → behavioral fixes [checked in branch and trunk]
*** Bug 309739 has been marked as a duplicate of this bug. ***
Am I correct in assuming that this bug would probably depend on bug 145320 to be fixed in order to fix this bug properly?
Assignee: mconnor → nobody
Status: ASSIGNED → NEW
QA Contact: mozilla → history
Depends on: 145320
Assignee: nobody → dao
Status: NEW → ASSIGNED
Attachment #283539 - Flags: review?(sspitzer)
Comment on attachment 283539 [details] [diff] [review] underline & cursor:pointer for winstripe (checked in) Is this wanted for Mac, too?
Component: History → Places
Whiteboard: partial patch
Target Milestone: Firefox1.5 → Firefox 3
QA Contact: history → places
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.
Attachment #283539 - Flags: ui-review?(beltzner)
Attachment #283539 - Flags: review?(sspitzer)
Attachment #283539 - Flags: review+
(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.
Attachment #283539 - Flags: ui-review?(beltzner) → approval1.9?
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
Attachment #283539 - Flags: approval1.9? → approval1.9+
Keywords: checkin-needed
OS: Windows 2000 → All
Hardware: PC → All
Summary: No hover highlighting (i.e. mouse-tracking) in History sidebar → No hover highlighting (i.e. mouse-tracking) in Bookmarks/History sidebar
(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.
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
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: Firefox 3 → Firefox 3 M9
Version: unspecified → Trunk
I'm not yet done here (comment 48), but thanks for the check-in.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → ASSIGNED
Attachment #283539 - Attachment description: underline & cursor:pointer for winstripe → underline & cursor:pointer for winstripe (checked in)
Attached patch follow-up patchSplinter Review
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
Attachment #284549 - Flags: ui-review?(mconnor)
Attachment #284549 - Flags: review?(sspitzer)
Comment on attachment 284549 [details] [diff] [review] follow-up patch r=sspitzer
Attachment #284549 - Flags: review?(sspitzer) → review+
Flags: blocking-firefox3?
Flags: blocking-firefox3? → blocking-firefox3-
Whiteboard: [wanted-firefox3]
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.
Attachment #283539 - Flags: approval1.9+
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.
Attachment #283539 - Flags: approval1.9?
Comment on attachment 283539 [details] [diff] [review] underline & cursor:pointer for winstripe (checked in) Re-approving as this bug was already checked in.
Attachment #283539 - Flags: approval1.9? → approval1.9+
Attachment #284549 - Flags: ui-review?(mconnor) → approval1.9?
Attachment #284549 - Flags: approvalM9+
Attachment #284549 - Flags: approval1.9?
Attachment #284549 - Flags: approval1.9+
Keywords: checkin-needed
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
Status: ASSIGNED → RESOLVED
Closed: 18 years ago18 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
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
Status: RESOLVED → VERIFIED
Flags: wanted-firefox3+
Whiteboard: [wanted-firefox3]
Depends on: 310884
No longer depends on: 310884
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
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: