65917 - :active neither hierarchical nor picky about what can be activated (pseudoclass)

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect, P1)

Description

[Aaron Kaluszka]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; 0.7) Gecko/20010109
BuildID:    2001010901

links that contain <acronym> do not take on their active style when clicked

Reproducible: Always
Steps to Reproduce:
Click on a link with <acronym> (the question mark + arrow appear)

Actual Results:  Nothing happens to the link style

Expected Results:  The link should take on its active style

Comment 1

[Hixie (not reading bugmail)]

this works fine for me using a recent build on Win2K... could you attach a 
small reduced test case (like, less than 1k) that shows what you mean?

I'm sorry I don't really understand...

Comment 2

[Richard Brodie]

I think I can see the problem: when a link contains another element, Mozilla 
doesn't apply the A:active rule when the element is clicked on. It will 
apply :active rules to the included element instead. I think this is OK now but 
likely won't be under CSS3, no?

You can see it (Win98/2001011904) on the W3C home page where the acronym links 
(e.g. CSS) in the left sidebar don't apply text-decoration:none when active. 
I'll attach a testcase where the behaviour is more obvious.

Comment 3

[Richard Brodie]

Attachment: Testcase for elements within links

Comment 4

[Boris Zbarsky [:bzbarsky]]

This problem is discussed somewhat in bug 5693.  It looks like the specification
is not very clear on what :active should be doing...  This should probably be
kept open as a separate bug to track :active, though.

ccing David.

Comment 5

[Keyser Sose]

Going ahead and Marking NEW.

Comment 6

[Jesse Ruderman]

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

Comment 7

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

The CSS3 UI specification is pretty clear about :active, and it's clear that
:active should not be hierarchical and it shouldn't apply to any-old-element, as
we let it do now.  So there is certainly a bug with active, but I don't think the
current description is correct.

Comment 8

[Boris Zbarsky [:bzbarsky]]

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

Comment 9

[Boris Zbarsky [:bzbarsky]]

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

Comment 10

[James Lariviere]

Anchored images would have to be an exception to this rule right (all the dupes)?

Image borders have always followed anchor colors.

:link:active img --> should change the image border like the anchor.

:link img:active --> you have to do this to get the "right" behavior and that
seems wrong when mozilla renders these for hover.
:link:hover img
:link img:hover

Comment 11

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

Why would images within anchors be an exception?  The html.css style rule for 
":link img, :visited img" (actually ":-moz-any-link img", but it's the same 
thing) says (I assume) 'border: medium solid' so that the border color for the 
image comes from its 'color' which is inherited from the anchor.  This means 
when the color of the anchor changes, the color of the image border changes as 
well.

Are there still some bugs on lack of proper invalidation for :hover?

Comment 12

[John Morrison]

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

Comment 13

[Pierre Saslawsky]

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

Comment 14

[Matthew T (active 1999-2002)]

A convenient testcase for this is the `bug pages' link at the top (and bottom)
of this bug report. 

Comment 15

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

See also bug 83031 about how :active probably shouldn't apply unconditionally.

Comment 16

[Pierre Saslawsky]

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

Comment 17

[Håkan Waara]

Please reconsider your milestone mozilla1.1; bold links don't work, this is
quite basic feature.

Nominating for mozilla0.9.9. This is as important as bug 5693 (milestone: 0.9.9,
[e-mail]) imho.

Comment 18

[Håkan Waara]

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

Comment 19

[Kevin McCluskey (gone)]

Mov to 0.9.9. Pierre will analyze the problem in 0.9.9.

Comment 20

[Kevin McCluskey (gone)]

Moving to Mozilla1.1. Engineers are overloaded with higher priority bugs.

Comment 21

[Kevin McCluskey (gone)]

Bulk moving from Moz1.1 to future-P1. I will pull from this list when scheduling
work post Mozilla1.0.

Comment 22

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

Based on CSS3 drafts, I don't think :active should be hierarchical.  However,
the current code is certainly wrong:

        if (activeContent) {
          // The nearest enclosing element goes into the
          // :active state.  If we fail the QI to DOMElement,
          // then we know we're only a node, and that we need
          // to obtain our parent element and put it into :active
          // instead.
          nsCOMPtr<nsIDOMElement> elt(do_QueryInterface(activeContent));
          if (!elt) {
            nsCOMPtr<nsIContent> par;
            activeContent->GetParent(*getter_AddRefs(par));
            if (par)
              activeContent = par;
          }
          SetContentState(activeContent, NS_EVENT_STATE_ACTIVE);
        }

Comment 23

[Håkan Waara]

All I know is that 

<a href="http://foo/bar"><b>click here</b></a> 

should highlight the link if you click it. My bug about this was duplicated
against this bug...

Comment 24

[Hixie (not reading bugmail)]

Hakan: what's not clear is that clicking an the <b> in that case should make the
<b> be :active. It could be argued that the click event bubbles up to the <a>
which then sets itself into :active. In any case that's still separate from
whether the :active pseudo-class is hierarchical or not.

It is atogether not clear how this bug should be fixed (unless we implement the
proposed CSS3 UI2 metadata stuff, which defines it in detail).

Comment 25

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

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

Comment 26

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

Retitling to say that it may not be a bug that :active isn't hierarchical, but
that we either need to make it hierarchical or make it pay attention to what can
really be activated.

Comment 27

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

When this is fixed (assuming we go down the "picky" route rather than the
hierarchical one) we should further reduce the quirk on global event selectors
to apply only to :hover.  See bug 96984.

Comment 28

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

Taking, since we should really fix this

Comment 29

[Boris Zbarsky [:bzbarsky]]

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

Comment 30

[Madhur Bhatia]

cc'ing myself

Comment 31

[Matthew T (active 1999-2002)]

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

Comment 32

[Aaron Kaluszka]

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

Comment 33

[Christopher Hoess (gone)]

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

Comment 34

[Johan Buret]

Using Mozilla Nightly Build 20020721 on Win98 SE

On the proposed testcase, Mozilla reacts as it would be expected...
If you click on the link but not on the acronym, the whole gets A:active style
If you click on the acronym, only the acronym gets acronym:active style

if you try to drag and drop on link, the underlining of the link remains red but
the rest of the link gets like Windoze selelction style 

Seems this bug has been solved...

Comment 35

[Aaron Kaluszka]

uhh no it hasn't... the point is that clicking on the acronym or bold should
activate the link.

Comment 36

[Jesse Ruderman]

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

Comment 37

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

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

Comment 38

[Boris Zbarsky [:bzbarsky]]

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

Comment 39

[Andrew Hagen]

Appending "(pseudoclass)" to summary to make this bug easier to find.

Comment 40

[Erich 'Ricky' Iseli]

correcting typo in "pseudoclass"

Comment 41

[Madhur Bhatia]

Bug 13258 says that this issue was fixed as of 1999-09-13. Any chances of this
gotten regressed or was it never fixed?

Comment 42

[Hixie (not reading bugmail)]

Never fixed.

Here's a testcase for this issue:
   http://www.hixie.ch/tests/adhoc/css/selectors/active/001.html

It's based on Hyatt and I's Dynamic UI draft for CSS3, which in turn is based on
the text in bug 115462.

Comment 43

[Anne (:annevk)]

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

Comment 44

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

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

Comment 45

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

Attachment: patch (make :active hierarchical)

Comment 46

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

Comment on attachment 152992 [details] [diff] [review]
patch (make :active hierarchical)

This isn't my favorite code, but this only took me just over half an hour, and
it would take quite a bit more time to clean it up...

Comment 47

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

Comment on attachment 152992 [details] [diff] [review]
patch (make :active hierarchical)

Actually, I need to modify some quirks in nsCSSStyleSheet.cpp.	I'll do that
later...

Comment 48

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

Attachment: patch (make :active hierarchical)

Well, it was just a comment, since the quirk would have been removed given the
opposite solution to this bug.

Comment 49

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 153012 [details] [diff] [review]
patch (make :active hierarchical)

r+sr=bzbarsky if you fix the "// The |!anc1->GetDocument()| case (that the old
hover node" comment to use "aNode1" instead of "the old hover node"

Comment 50

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

Fix checked in to trunk, 2004-07-14 15:27 -0700.

Comment 51

[Aaron Kaluszka]

Verfied fixed on trunk.... will this make it to the branches?

I also noticed that the "active link" box wraps only the within-link element and
not the whole link itself... is that what we want?  Should another bug be opened
for that?

Comment 52

[Aaron Kaluszka]

Filed bug 253154 for comment 51.

Comment 53

[Martijn Wargers (dead)]

I think this caused bug 257719. I've backed out the patch for this bug, and
after that I can't see bug 257719 anymore.

Comment 54

[Kevin Brosnan]

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

Comment 55

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

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

Comment 56

[Boris Zbarsky [:bzbarsky]]

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

Comment 57

[Jesse Ruderman]

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

Comment 58

[Stefan [:stefanh]]

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

Comment 59

[David W. Fenton]

(In reply to comment #53)
> I think this caused bug 257719. I've backed out the patch for this bug, and
> after that I can't see bug 257719 anymore.

If the patched was backed out, then how can it be fixed?

I see the bug present in Mozilla 1.7.12 on Win2K, and with Firefox 1.0.7 (which is based on the same version of Mozilla).

There is an inconsistency in the treatment of child elements of items with pseudoclasses, as for images, A:HOVER applies to image in side the link, while for A:ACTIVE, it does not. Seems to me it should be one way or the other.

The whole discussion of this, with a host of duplicate and closely related bugs seems to me to show that nobody has really though this one through in any organized fashion.

Comment 60

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

(In reply to comment #59)
> (In reply to comment #53)
> > I think this caused bug 257719. I've backed out the patch for this bug, and
> > after that I can't see bug 257719 anymore.
> 
> If the patched was backed out, then how can it be fixed?

He meant he backed it out in his copy, not that he committed the backout.

> I see the bug present in Mozilla 1.7.12 on Win2K, and with Firefox 1.0.7 (which
> is based on the same version of Mozilla).

It was fixed after those versions.

Comment 61

[David W. Fenton]

(In reply to comment #60)
> > I see the bug present in Mozilla 1.7.12 on Win2K, and with Firefox 1.0.7 
> > (which is based on the same version of Mozilla).
> 
> It was fixed after those versions.

OK, but I don't quite see where the bug says this. Perhaps I'm just not reading the header correctly, but I don't see where it says that the patch (which is listed for July 2004) was incorporated into a version of Mozilla. Perhaps that's implied by the 1.8 target milestone? Perhaps that's self-evident to somebody who is actively working with the project, but for somebody like me, who just comes here when I discover a bug and want to investigate it, it's not very evident.

If there were more clarity about this in the comments, perhaps fewer people would be filing duplicates.

I certainly wasted a lot of time on it this evening, and it's not worth it to me to write my CSS to work only for a fixed version that hasn't yet been officially release, so I'm forced to abandon my usual adherence to CSS 1 only and apply an ACTIVE pseudoclass to my IMG tag (in CSS 1, the ACTIVE and HOVER pseudoclasses applied only to links). 

I'll wait until a full release to test it to see if it's actually fixed, but the amount of diddling around on this one that is evident from the history of this bug and all the related ones doesn't make me optimistic about it being fixed correctly. I certainly don't understand why a bug that was first reported in 2001 is only being fixed almost 5 whole years later. It's especially frustrating when I see that the hated IE just does it right and always has (back to IE 5.x, with nearly acceptable results even in IE4).

Sorry for the rant. It's just been a very frustrating evening. I'm accustomed to wasting time like this working around problems in IE and Opera and Safari, and not with Mozilla. 

Comment 62

[Robert Kaiser]

A resolution of "FIXED" always means "fixed on trunk", where "trunk" is the current development code (also called CVS HEAD in some other projects). If you're not satisfied with the fact that in this case, no stable version of this code was released over a period of around one and a half years, you have to criticise the release people, and not folks in this bug report (release people don't read those bugs usually).
BTW, your "almost 5 years" are 3.5 years actually. Anyways a good advice to not waste evening searching for bugs that have been fixed on trunk is to fetch a trunk nightly of Firefox or SeaMonkey and look if it still happens there. If not, then the hard time of waiting for a stable release with this code begins (which again is up to release people) ;-)

Comment 63

[David W. Fenton]

(In reply to comment #62)
> A resolution of "FIXED" always means "fixed on trunk", where "trunk" is the
> current development code (also called CVS HEAD in some other projects). . .

As I said, this kind of thing would likely be clear to someone who is a regular participant in the development process, but to someone like me, who is just a user who wants to know if the bug is known and fixed, it's not too helpful to hide this kind of thing behind language that to an outsider is opaque and technical.

> . . . If
> you're not satisfied with the fact that in this case, no stable version of this
> code was released over a period of around one and a half years, you have to
> criticise the release people, and not folks in this bug report (release people
> don't read those bugs usually).

How am I (and all the people who've filed dupes of this bug) supposed to know that? And where do I contact them to ask them why it took so long (I assume it was because of the significant architecutural issues of which this bug was only one facet)?

> BTW, your "almost 5 years" are 3.5 years actually. . . .

Excuse me? The bug was filed Jan 18, 2001. Today is Nov. 28, 2005, about a month and a half before the 5th anniversary of the filing of this bug, and there is no stable release version with the bug fixed. You can only get 3.5 years if you ridiculously choose the date the patch was filed, which doesn't do *me* a lick of good as a web page developer because for understandable reasons, hardly anyone is using the nightly builds, which are the only place where you can get the fixed version.

> . . . Anyways a good advice to not
> waste evening searching for bugs that have been fixed on trunk is to fetch a
> trunk nightly of Firefox or SeaMonkey and look if it still happens there. If
> not, then the hard time of waiting for a stable release with this code begins
> (which again is up to release people) ;-)

I encountered a problem developing a web page. I needed to confirm a bug in Mozilla to know if I would have to kludge my HTML/CSS in order to get it to work properly for all the people out there using the release versions of Mozilla (in which this doesn't work right). Downloading a nightly build just tells me that Some Day Real Soon Now everybody who downloads the next release version will have the fix. But it does diddly squat for all the myriad buggy older installations of Mozilla/Firefox already out there.

I think your attitude rather misses the point of my criticism. I understand that things can't happen magically overnight in a project of this magnitude. But it seems to me that two things about the process could be vastly improved:

1. the resolution of architectural questions (in this case, how to interpret how the CSS 1 and CSS 2 standards should actually render the mouse-related pseudoclasses) should be done in some kind of organized fashion, rather than piecemeal in the discussion for individual bugs (each of which is only one aspect of the larger set of problems).

2. when a bug is fixed, someone should be responsible for making sure the bug comments indicate the release path for the patch in some kind of user-comprehensible manner.

I strongly suspect this is not the place for this discussion, and if there's somewhere else that I should be having it, please let me know, and I'll take it there.

And I'm not trying to be difficult. I love Mozilla/Firefox and have been promoting it to all my clients since I started using it as my default browser with Mozilla 0.9.3 (August 2001), but with the collapse of IE and the massive success of Firefox as a much safer alternative browser, it frustrates me when details in the rendering engine persist into the public releases for so very long. The number of duplicate bugs filed should indicate the extent to which this was actually a problem experienced by a significant number of people (CSS rollovers using transparent GIFs don't work properly because of it, which is a pretty commonly used technique). I'm just frustrated at having to waste so much time solving a problem that has been known for nearly 5 years.