102479 - middle-clicking a link should give :active state to link

Status: NEW

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Niels Aufbau]

Steps to reproduce:
1. Go to http://www.mozilla.org/.
2. Middle-click a link (for open in new window).

Actual result: 
Link gets :focus (dotted border) forever but is never :active (red).

Expected result: 
Link gets :focus forever and :active at least while middle mouse button is held
down.  (Internet Explorer seems to keep links :active as long as they have
focus, which makes it easier to see which link has focus.)

Note that this works fine if you hold down control and use the left mouse button
to click a link, which otherwise does the same thing as middle-clicking.

Comment 1

[Boris Zbarsky [:bzbarsky]]

over to events.

Comment 2

[bugs]

I think :active would be also expected with the right button, not just the left
and middle.
The only question is: should it remain active for the short time the button is
held down, or the long time while the pop-up menu is active? I vote for the latter.

Comment 3

[Pham]

.

Comment 4

[Vedran Miletic]

retargeting

Comment 5

[Steve Ward]

This bug also applies to OS: Windows XP and Product: Firefox and probably more.

Comment 6

[Ben Basson]

-> All/All

Bug still present on trunk, and affects other things too, like html:button
activation via keys and middle and right clicks that don't trigger context menus
(on buttons or otherwise). This is quite bad for feedback on forms and suchlike,
probably accessibility too.

Boris (apologies if you're not the person to CC about this), should this be
reassigned? Is there any chance of targetting this for sometime during the 1.9
cycle?

Comment 7

[Boris Zbarsky [:bzbarsky]]

We need a clear definition of what it means to be :active before anything
happens here...

Comment 8

[Ben Basson]

http://www.w3.org/TR/CSS21/selector.html#dynamic-pseudo-classes

:active is a state that indicates activity on an element. It's the visual
feedback you get when clicking and holding a button (it appears pressed down) or
a link (in bugzilla, the link text changes to red on mousedown, then the
:visited colour on mouseup).

Gecko already handles this correctly for left-clicks, but not middle or right.
Another good example is clicking the home button.

Left click - home button is pressed in on mousedown.
Middle click - home button is not pressed in on mousedown.

The "Commit" button here is an example of this not working nicely with the
spacebar (or keys in general). The button is functional, but when you press a
key, the button stays "up" instead of being pressed "down". If you left click
the button, it is pressed "down" as expected.

If you need further clarification, I'll see if I can get some more spec coherant
people to comment.

Comment 9

[Boris Zbarsky [:bzbarsky]]

I'm aware of what the spec says.  The problem is that it's nearly useless in
practical applications.

Fwiw, I think the code that limits :active to the left mouse button is at
http://lxr.mozilla.org/seamonkey/source/content/events/src/nsEventStateManager.cpp#1987

Comment 10

[Ben Basson]

I'll agree that there are few uses for middle/right button feedback, but I think
the lack of feedback for keyboard events is a more serious issue - especially if
a function is triggered that gives little feedback itself, such as refreshing a
display when the data source is unchanged.

Granted, that's an interface issue for the app developer, but I can imagine such
problems arising. 

Are there circumstances (other than right clicking and triggering a context
menu, which seems to function correctly here) where an event shouldn't set
:active on approrpriate elements? Presumably there was motivation behind
originally limiting this to the left mouse button.

Comment 11

[Boris Zbarsky [:bzbarsky]]

You can look up the CVS blame for that code and see when it was checked in, and
for what bug.  Sometimes that helps.

Comment 12

[Ben Basson]

Looks like that was the fix for bug 45533, which concerns right clicking causing
buttons to depress, but have no net effect (since only left clicking triggers
oncommand).

I'm beginning to see why this bug isn't fixed, since I can't see any easy way of
deciding beforehand whether it's appropriate to set :active for anything other
than hyperlinks (where it's known that the effect is intended).

Perhaps the best way to solve this would be to provide a way to set the :active
state. This could then be dealt with from chrome for hyperlinks (and fix this
bug as-is) and would give developers a way to provide visual feedback where they
wish. I wouldn't know where to begin along this line of thinking though.