Closed Bug 65917 Opened 24 years ago Closed 20 years ago

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

Categories

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

defect

Tracking

()

RESOLVED FIXED
mozilla1.8beta1

People

(Reporter: megabyte, Assigned: dbaron)

References

()

Details

(Keywords: testcase, Whiteboard: [Hixie-P2][patch])

Attachments

(2 files, 1 obsolete file)

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
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...
QA Contact: chrisd → ian
Whiteboard: WORKSFORME?
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.
Attached file Testcase for elements within links (deleted) —
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.
Hardware: PC → All
Summary: <acronym> disables active link style → :active not hierarchical
Whiteboard: WORKSFORME?
Going ahead and Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: testcase
*** Bug 69704 has been marked as a duplicate of this bug. ***
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.
*** Bug 93316 has been marked as a duplicate of this bug. ***
*** Bug 94615 has been marked as a duplicate of this bug. ***
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
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?
*** Bug 96741 has been marked as a duplicate of this bug. ***
*** Bug 95951 has been marked as a duplicate of this bug. ***
A convenient testcase for this is the `bug pages' link at the top (and bottom) of this bug report.
Summary: :active not hierarchical → :active not hierarchical (some links not highlighted on mousedown)
See also bug 83031 about how :active probably shouldn't apply unconditionally.
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla1.0
*** Bug 62289 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla1.0 → mozilla1.1
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, hyatt@netscape.com) imho.
Keywords: mozilla0.9.9
Whiteboard: [Hixie-P2]
Depends on: 115462
*** Bug 56228 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla1.1 → mozilla1.0
Mov to 0.9.9. Pierre will analyze the problem in 0.9.9.
Target Milestone: mozilla1.0 → mozilla0.9.9
Moving to Mozilla1.1. Engineers are overloaded with higher priority bugs.
Target Milestone: mozilla0.9.9 → mozilla1.1
Bulk moving from Moz1.1 to future-P1. I will pull from this list when scheduling work post Mozilla1.0.
Priority: P3 → P1
Target Milestone: mozilla1.1 → Future
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); }
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...
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).
*** Bug 83031 has been marked as a duplicate of this bug. ***
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.
Summary: :active not hierarchical (some links not highlighted on mousedown) → :active neither hierarchical nor picky about what can be activated
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.
Taking, since we should really fix this
Assignee: pierre → dbaron
Severity: normal → major
Status: ASSIGNED → NEW
Target Milestone: Future → mozilla1.1beta
*** Bug 144320 has been marked as a duplicate of this bug. ***
cc'ing myself
*** Bug 100203 has been marked as a duplicate of this bug. ***
*** Bug 149304 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla1.1beta → mozilla1.2alpha
*** Bug 75082 has been marked as a duplicate of this bug. ***
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...
uhh no it hasn't... the point is that clicking on the acronym or bold should activate the link.
*** Bug 159709 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla1.2alpha → Future
Blocks: 142898
*** Bug 181664 has been marked as a duplicate of this bug. ***
*** Bug 183661 has been marked as a duplicate of this bug. ***
Appending "(pseudoclass)" to summary to make this bug easier to find.
Summary: :active neither hierarchical nor picky about what can be activated → :active neither hierarchical nor picky about what can be activated (pseduoclass)
correcting typo in "pseudoclass"
Summary: :active neither hierarchical nor picky about what can be activated (pseduoclass) → :active neither hierarchical nor picky about what can be activated (pseudoclass)
Keywords: mozilla0.9.9mozilla1.4
Bug 13258 says that this issue was fixed as of 1999-09-13. Any chances of this gotten regressed or was it never fixed?
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.
Blocks: 243459
*** Bug 13258 has been marked as a duplicate of this bug. ***
*** Bug 246223 has been marked as a duplicate of this bug. ***
Attached patch patch (make :active hierarchical) (obsolete) (deleted) — Splinter Review
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...
Attachment #152992 - Flags: superreview?(bzbarsky)
Attachment #152992 - Flags: review?(bzbarsky)
Status: NEW → ASSIGNED
Whiteboard: [Hixie-P2] → [Hixie-P2][patch]
Target Milestone: Future → mozilla1.8beta
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...
Attachment #152992 - Flags: superreview?(bzbarsky)
Attachment #152992 - Flags: review?(bzbarsky)
Well, it was just a comment, since the quirk would have been removed given the opposite solution to this bug.
Attachment #152992 - Attachment is obsolete: true
Attachment #153012 - Flags: superreview?(bzbarsky)
Attachment #153012 - Flags: review?(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"
Attachment #153012 - Flags: superreview?(bzbarsky)
Attachment #153012 - Flags: superreview+
Attachment #153012 - Flags: review?(bzbarsky)
Attachment #153012 - Flags: review+
Fix checked in to trunk, 2004-07-14 15:27 -0700.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
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?
Flags: blocking-aviary1.0RC1?
No longer blocks: 142898
Flags: blocking-aviary1.0PR? → blocking-aviary1.0PR-
Flags: blocking-aviary1.0?
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.
Flags: blocking-aviary1.0? → blocking-aviary1.0-
*** Bug 284205 has been marked as a duplicate of this bug. ***
*** Bug 290600 has been marked as a duplicate of this bug. ***
*** Bug 83031 has been marked as a duplicate of this bug. ***
*** Bug 289008 has been marked as a duplicate of this bug. ***
*** Bug 305618 has been marked as a duplicate of this bug. ***
(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.
(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.
(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.
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) ;-)
(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.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: