309739 - History items act like links but don't look like links

Status: RESOLVED DUPLICATE of bug 251910

(Firefox :: Shell Integration, defect)

Description

[Andre Sihera]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4

Single clicking on the entry loads the web page when the expected action
is to purely hightlight the option so I can then:

1) scroll up and down but return to the place where I clicked the item
2) deselect the item using "CTRL+click" as it was the wrong page
3) right-click on the item to get a context menu.
4) double-click the item to *confirm* my intention to open the page, having
   gone off and opened a new tab, or having selected a tab that I want to
   overwrite (for example).

This is a fundamental break of UI integration on the Windows platform and
is very, VERY frustrating. Not least because Windows users who don't expect
this behaviour will be always blowing away the contents of some other tab
when they don't expect it, and then have to use the back button.

The single/double click mechanism on list items is a core part of Windows
UI functionality. This needs to be fixed as soon as possible.

* It is not the job of an extension to be fixing this kind of problem.
* Even if there is an extension that can fix the problem it is seriously
* unwise to assume that, because there is an extension to fix this, your
* average user will be able to find out about the existence of the
* extension and then install it.
*
* Firefox may be good but user-ubiquity will be impossible if they have
* to install numerous extensions to fix fundamental UI integration breaks
* like this. It should be fixed in code.


Reproducible: Always

Steps to Reproduce:
1. Open the history bar.
2. Single left-click on an entry.

Actual Results:  
Single clicking on the entry loads the web page


Expected Results:  
Single clicking on the entry should only *select* the entry, allowing me
from there to either select another entry or deselect the entry. Double-
clicking on the entry should load the web page.

Comment 1

[Andre Sihera]

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

Comment 2

[Andre Sihera]

> ...very, VERY frustrating. Not least because Windows users who don't expect
> this behaviour will be always blowing away the contents of some other tab
> when they don't expect it, and then have to use the back button.

I forgot to add that this is especially true when the page you just blew away
was some non-cacheable content like the results of a search, form submission, etc.

Comment 3

[Martijn Wargers (dead)]

My IE6 version also loads history items on single-click in the history sidebar.

Comment 4

[Andre Sihera]

Yes, but in IE6 it is the *look and feel* that makes that ok, is it not?

In IE6, like in IE5, the history list is a set of HYPERLINKS, not a list box.
As you hover over each history link in IE the pointer changes to a "hand" which,
in Windows specifically, is different from the normal mouse pointer. Therefore,
visually, people see hyperlink they know single-click. If they see list box they
think double-click.

The functionality is not the issue. If we want single-click then the list items
must be made to look like items that support a single click; they should not
look like UI elements that look like they require a double click to activate
them.

It's about UI consistency.

Comment 5

[Andre Sihera]

> In IE6, like in IE5, the history list is a set of HYPERLINKS, not a list box.
> As you hover over each history link in IE the pointer changes to a "hand" which,
> in Windows specifically, is different from the normal mouse pointer...

The links also have a temporary underline appear underneath them as a normal
hyperlink would in the actual browser pane; more visual evidence that what looks
like a list item is in fact *not* a list item and so behaves differently.

Comment 6

[Jesse Ruderman]

Dup of bug 251910?

Comment 7

[Mike Connor [:mconnor]]

*** This bug has been marked as a duplicate of 251910 ***