User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1 This is a inconsistency: A bookmark (in the side bar) can be single-clicked to load, a history item (in the side bar) must be double-clicked to load. I believe that a single click is just fine for a history item as well. Reproducible: Always Steps to Reproduce:

Confirming with 20030826 build on WinXP

if we're asking for History to change, then it should go to History

Seeing in Linux as well --> All Definitely an annoyance

Oh. I would prefer single click to select, double click (or drag and drop) to take action (Open). I would change the bookmark behaviour, which would also match the Bookmark Manager, but if I am in a minority of one ... Ben.

indeed.

(In reply to comment #5) > indeed. Indeed what? Are we standardising on single-click or double-click?

Vote for single click

we've moved to double click in other places. Single click makes it difficult for some users to use context menus, so we should match bookmarks manager and make it double click.

Changing my vote to double-click actually. It is better to be able to select several items at once and to delete it.

standardize on single click across UI - matches IE, click action (load of URL) should not be invoked when right clicking on links.

Shouldn't single or double click be determined by the user's OS settings? I *HATE* double-clicking (it's a complete waste of time) so to be forced to do it in certain parts of the interface is annoying. Winzip has an option that checks whether double or single click has been set as default for the OS, and then it just matches that setting, so everyone gets what they want. Personally I would like to see single click all the way. You don't double click menus, or buttons, or web links, so why double click anywhere else? (unless it is a secondary action). Of course there should be a double click method as an option (for people who want it) but it should not be made compulsory.

P.S. Internet Explorer is far more consistent in this regard. It's History and Favorites side bars work in exactly the same way as the rest of the interface. There is no need to keep switching back and forth between different methods based on where you are in the program.

fixed on the trunk

sorry, wrong bug

The bookmarks sidebar should use a single click mouse action. Using a dubble click mouse action would imply that the "bookmarks Toolbar" should work in the same way. Which is not right. The Bookmarks manager doesn't have to be consistent with the rest because it is designed to manage bookmarks. The bookmarks sidebar, the bookmarks toolbar and the drop down menu (Bookmarks) are all designed to access bookmarks. These three have to be consistent (single click). The history sidebar should have the same behavior as the bookmarks sidebar (single click).

Isn't this a history sidebar bug and not a bookmarks bug?

(In reply to comment #17) > Isn't this a history sidebar bug and not a bookmarks bug? Yes, it is a history sidebar bug

Comment on attachment 152933 [details] [diff] [review] fix this leaves out changes that should happen, as well as opens up some oddball side effects. Better patch coming.

fixed Bug 255027 by not showing a context menu if no items are selected. supports all Ctrl/Shift/Ctrl+Shift key modifiers in the same way as bookmarks sidebar does. Prevents clicking on a twisty from triggering a load event (one of the problems from the previous patch). Supports middle-clicking to open in a new tab etc, including the shift modifier to flip the foreground/background action. removes the select all menuitem, and a fair bit of unneeded code.

I don't think that disabling the context menu if no item is selected is a good idea. That's not what is done in the bookmarks panel. It may be used to delete or bookmark single items and delete all the content of a folder. And the same for select all. I am not sure if the result of deleting all the selection work correctly in every view, but it is also really useful. I know people that never open the preference dialog...

we do odd things if there's no selection, but there's a patch to suppress the context menu if there's no selection. select all doesn't coexist with a single-selection tree. After this patch, users can still delete entire days/sites. If they're relying on the history panel to protect their privacy, they're ignoring cookies, saved form info, and saved passwords, so its a false economy by not pushing them into the privacy panel.

Comment on attachment 157619 [details] [diff] [review] better patch since IE doesn't provide a select All option, this patch should be fine. A bit of refactoring with the functions handleHistoryClick, OpenURLLinkIn and OpenURL may be nice to do, but shouldn't block this patch. r=me if you change OpenURL to openURL and bonus if you change also OpenURLLinkIn to openURLLinkIn.

Comment on attachment 157619 [details] [diff] [review] better patch I'll make the changes to the casing as noted by Pierre on checkin, but this should really go in before PR.

Comment on attachment 157619 [details] [diff] [review] better patch a=asa for aviary checkin

confirmed fixed on Windows Firefox Branch 2004-09-10-08-0.9 and Mac Firefox Branch 2004-09-10-07-0.9

Just to inquire, it's intentional that you can't select more than two entries in the sidebars now (via click & Shift+Down or Ctrl-click & Ctrl-click; like you can do for select multiple fields), right?

that's correct. Multiple selection only works right with double-click default actions, not single click.

Is the lack of multiple selection due to a limitation of XUL apps (and how they handle click detection)? or was it a design decision?

I fear that with these changings the history sidebar loses the functionality to select and delete multiple items. Or is this functionality kept? (This is why I have submitted bug 257411.)

(In reply to comment #29) > Is the lack of multiple selection due to a limitation of XUL apps (and how they > handle click detection)? or was it a design decision? Design decision, absolutely. We can do lots with clicks. Click, then shift-click, would result in loading the page, then deleting it from history (since that's the only useful thing that multiple selection did here). I guess you could ctrl-click, then shift-click, but that's really unintuitive and not how trees should work with single-click action. Plus, if we're going for consistency, respecting the same click modifiers in the same way as the bookmarks sidebar and bookmarks themselves.

Please add in the ability to revert to the old style history sidebar behaviour. I like to be able to delete multiple items from my history and hitting delete 20 times is absurd. Also it's very annoying for it to respond to single click as I tend to left click before right click(and many others do too!) and it is a pain having to hit back everytime. Perhaps assign ctrl+middle click and shift+middle click to what was the old behaviour with the left click? Or perhaps even use the arror keys to change which item is 'in focus' so to speak and use space to keep it selected? Eg. I use the arror keys to navigate along the tree and hit space on the ones I want deleted, when I'm finished I can then hit delete, or just use shift+space to select the first and last of a range to be selected? Multiple selections are also good for when someone wants to open multiple items from the history in multiple tabs. Basically just *some* method of getting a multiple selection.

(In reply to comment #32) > Please add in the ability to revert to the old style history sidebar behaviour. > I like to be able to delete multiple items from my history and hitting delete 20 > times is absurd. > Also it's very annoying for it to respond to single click as I tend to left > click before right click(and many others do too!) and it is a pain having to hit > back everytime. > Perhaps assign ctrl+middle click and shift+middle click to what was the old > behaviour with the left click? > Or perhaps even use the arror keys to change which item is 'in focus' so to > speak and use space to keep it selected? > > Eg. I use the arror keys to navigate along the tree and hit space on the ones I > want deleted, when I'm finished I can then hit delete, or just use shift+space > to select the first and last of a range to be selected? > > Multiple selections are also good for when someone wants to open multiple items > from the history in multiple tabs. > > Basically just *some* method of getting a multiple selection. I second this request. I really miss being able to select specific entries and delete them all together.

Agree with Leo and Jeff. The best solution is to make it act like on KDE Linux. If someone holds ctrl on keyboard, then he should be able to select more than one link. If it is not possible to get this until 1.0 then users should be at least able to revert to old behaviour, or probably old behaviour should be default. Maybe the *best solution* is to switch to old behaviour and resolve user cofusion with visual feedback - pointer over bookmarks won't be like pointer over history (part of bug 258510). Unfortunatly, there is no history manager, and you can't play with this.

that WAS our behaviour. We had a choice between two incompatible (and not easily interchangeable) designs, and we collectively decided that this behaviour was more consistent and appropriate within the greater aspect of the app. We're not going to add a bunch of conditional code to make it an either/or situation. If anything, I would suggest that it would be relatively trivial to hook up an extension that would provide the old behaviour, simply by getting the older versions of history.js and history-panel.xul and renaming/packaging them.

I have to agree with Mike's comment #35, the devs really should not be spending their time putting inconsistency into the interface (an especially not when they have just gone through the process of removing it). I am all for spending time fixing interface issues that break the conventions of the Operating System on which it is run (or which deviates from the design standards set for the program itself) but not if such changes break consistency or adds unnecessary complexity. Of course, it is perfectly easy to have multiple file selection *AND* single click activation at the same time (this is how I have my entire Windows OS set up) and I filed a bug about this very issue 2 months ago (Bug 251910). However, I don't know if XUL has such capabilities. That is why I asked if the current method of Sidebar single-click was by design or due to XUL limitations (comment #29) and I was told that the current behaviour was very much by design. So, given that this is entirely intended behaviour, I did not bother to mention my single-click multiple selection bug. My preferred solution (which would solve ALL such problems like this in one go) is described by Ivo Marques Martins in his Bug 226256. But I don't know if XUL is capable of doing this. Even if the current Sidebar implementation is to be kept exactly as it is now, then I would suggest that at least the bookmarks should change visually upon mouseover (as this is standard behaviour for anything that is activated by a single click). You only need to look through the rest of Firefox to see this principal in action.

I'm finding the single-click to launch bookmark from side bar incredibly frustrating. Frequently I find myself clicking on a bookmark with expection that I will highlight it (select it) for a subsequent operation such as dragging, getting properties. Also related, is a bug a just filed, in which dragging a bookmark in the sidebar has the side-effect of launching it after the drag is complete. I believe this is all due to launch by single-click. Can't this be a preference. Thanks.

I'm finding the single-click to launch bookmark from side bar incredibly frustrating. Frequently I find myself clicking on a bookmark with expection that I will highlight it (select it) for a subsequent operation such as dragging, getting properties. Also related, is a bug a just filed, in which dragging a bookmark in the sidebar has the side-effect of launching it after the drag is complete. I believe this is all due to launch by single-click. Can't this be a preference. Thanks.

in addition comment #30 > I fear that with these changings the history sidebar loses the functionality to > select and delete multiple items. Or is this functionality kept? > (This is why I have submitted bug 257411.) Please have a look at Bug 261622. I think this would be a better solution for such problems than mutilating Firefox.

(In reply to comment #39) (comment #10 says that this is only be done to behave like IE.)

Wow! 40 comments ... See my comment 4 and the vote in comment 9. See also comment 35 - have we started something that is hard to stop? See comment 36: it should go without saying that objects with single-click behaviour should have have hover or mouse-down feedback. We were only asking for standardising or harmonising. The request for single click to select and double click to open was a perfectly reasonable one. We now have single click to open, that is the objects in the sidebar act as buttons rather than icons. The stimulus for this (comment 10) was to match IE, though other reasons exist. This use of button-behaviour - single click for action denies: multiple selection (comment 28) - we do not expect to select multiple buttons deletion (comment 30) - buttons have only one action, in this case open select before action (comment 32) - we don't select buttons we click them drag and drop (comment 37) - we don't expect to be able to edit buttons in browse mode I am sorry I come across like a sore loser, so I repeat, if I am in a minority of one, fair dos; but as others have requested please also handle bug 226256 and bug 251910 .

The Seamonkey equivalent of this bug report was bug 20455, which includes (gasp!) actual usability test results. Those who do not learn from history are condemned to repeat it ...

Sorry to spam you all with add an additional comment when I have already stated my case earlier (in Comment #36), but I do have an important point that I would like to make on this topic. There is constant talk of "single click" this and "double click" that, rather than using the correct concepts of "selection" and "activation". By wrongly using terms like "double click" (when in fact they actually mean "activate") it causes untold confusion because it implies that the method of 2 clicks is going to be forced upon ALL users (even those that have their OS set to single-click activation). Invariably it is "double-clickers" who are the ones that are so lax and inaccurate with their terminology (see Bug 229217). A single-click user would never use the phase "double-click" to mean 'launch' or 'activate', because they never actually double-click anything (except when forced to do so in something like the Windows System Tray). I have just looked at the SeaMonkey bug 20455 (quoted in Comment #42) and it's full of squabbling over exactly how many clicks should or should not be used in each individual panel. This argument would have been greatly simplified if inveterate double-clickers did not keep assuming that everyone uses the same click activation system that they do. By sticking to the concepts of selection and activation, they could have concentrated on how the panels should actually function (and leave aside the issue of the actual number of clicks to be dealt with by the OS). As I said in my Bug 251910, it is perfectly possible to have single-click activation and still have multiple file selection that works in a way that both single-click and double-click users can use (without either having to change the selection behaviour that they are familiar with). Comments (in bug 20455) such as "there may be cases like Bookmarks where double-click is the correct answer" are, in my view, totally wrong. Double click is *NEVER* the correct answer on a system where the OS has been set to single-click activation. It's just as wrong as forcing English dialogs on an OS that is set to a different language. It would be like using the terms "left click" and "right click" literally (instead of 'primary mouse button' and 'secondary mouse button'). If you take these terms literally and then made a program so that you HAD to "right click" in certain places, then it will make that program very user hostile for left-handed people (who have their mouse buttons swapped so that their right button invokes the primary action). So the issue is not left button / right button, but primary / secondary. Likewise the issue is not 'single click' or 'double click', but 'select' or 'activate'. That is why I voted for Bug 226256 which, if it were possible to implement, would solve this problem for everybody once and for all.

Since sidebar history and bookmarks are now styled like links (blue, underlined, single-click) they should take the typical link (hand) cursor on hover. This is what IE does, and it makes good sense. (see comment 13) It would also (IMHO) be more readable if the links had no underline, and applied the underline on hover. That's seems to be the more "contemporary" link style (doing something on hover, underline or color). Doesn't really need to be blue either. Maybe black, then blue with underline on hover.

I totally agree with Comment #43. Firefox does not hardcode left / right clicks and force end users to use the mouse buttons that the programmers have explicitly specified. Instead, anyone can go to Control Panel, swap their mouse buttons and Firefox will automatically respond and match those swapped button settings throughout the application. But if you use the exact same Control Panel mouse dialog to switch between single and double click, then Firefox just ignores any change in this setting. This is because Firefox programmers are concentrating on specifying the actual number of clicks that should be used in certain places within the application, rather than dealing with selection and activation (as mentioned in the comment above). The result is that Firefox totally ignores and over-rides the user's chosen click activation settings (which is very bad). I therefore vote for Bug 226256. Let each user's Operating System settings determine how many clicks are needed to select and launch items within Firefox.

I noticed (and so did Tracy and Marcia) that ctrl+clicking in the history sidebar now does non-continguous selection. is this expected? in addition, ctrl+doubleclicking no longer opens history sidebar items in a new tab --is this also expected?

yeah, expected as in Ben changed the modifiers to do multi-selection instead of supporting the click modifiers that were implemented to match the bookmarks sidebar. I'm not a big fan of this step.

I am a huge fan of Ben's modifier patch (as are many other people). This is definitely a step in the right direction and much better than the ugly horrible mess that was implemented previously (and which was thankfully backed out after much user protest).

if the point was to make the sidebars behave consistently, then its a step in the wrong direction. Single-click activation + multiple selection is pretty ugly. If you really want history management then the extension that brings back history manager from seamonkey is a vast vast improvement in terms of power and usability. I've seen relatively little user protest, perhaps you can point me to where this large-scale negative feedback came from.

The History functionality in FireFox is what turned me off from FireFox back to Mozilla. I find it almost unusable; it is a complete step back from Mozilla. Single-click activation is very unintuitive (not only for me). It is not a menu which you open temporarily and expect to close immediately after selection. It is a window which you open to work with, make a selection or multiple selections, then make an action (activate/delete/copy etc.). I sometimes want to select an item and change sorting/grouping criteria. I often want to select item and go up and down with arrow keys. Bookmarks should also behave the same way. The design goal to follow IE is not convincing: why go from good to bad? Not possible to search by location. Many pages have the same title and it’s impossible to find the right page. In addition, I often remember the location (or part of it) and inability to search by location makes History almost unusable to me. (I always search History by Location, never by Title) I would prefer to have History in the separate window (or to have an option to do so). I don’t like to open/close sidebar and every time. In general, the design decisions in Mozilla (not only with History) were much better.

You can do multi-select now, if you click to the left of the tree item, it does selection, not activation. If you want something a little more advanced/heavy-duty, there's an Enhanced History Manager extension out there that does a much better job of "managing" history. The sidebar panels are generally unsuited for any advanced management-style interface, and we're discussing what we can do for 1.5 to improve history management, or if history "management" is a generally little-used feature and should be relegated to an extension. Resolving, the trunk merge will get this.

(In reply to comment #51) > You can do multi-select now, if you click to the left of the tree item, it does > selection, not activation. I don't think this should be resolved. You can multiple select with the trick above, but then you can't get a contextual menu, so you can't really do anything with that selection (hitting the delete key doesn't do anything either). And having different behavior when clicking on the icon/name and the empty space next to the icon/name doesn't seem very usable. I still think this should be a 1.0 blocking bug, but if you want to put this off for post 1.0, fine. But you shouldn't resolve it. (comments in bug 259658 brought me here)

verified. This bug was meant only for the single-click vs double-click consistency of sidebar items across bookmarks and history. If needed, please open bugs for other items that creeped in here.

(In reply to comment #53) > verified. > > This bug was meant only for the single-click vs double-click consistency of > sidebar items across bookmarks and history. I hear claim that you now need to double click in the history pane. But in 1.5b1, on linux, if I single click, and try to do a multi-selection, then I get a window opening up on me with the url that was last clicked. This is *definitely* contrary to my window manager policy, and makes deleting multiple entries impossible. Did I read something wrong, or has the behaviour reverted back to the annoying single click behaviour, without this bug being updated?