The default bug view has changed. See this FAQ.

selectors with adjacent sibling combinator missed by dynamic style reresolution [SELECTORS-DYNAMIC] (:hover +)

VERIFIED FIXED in mozilla1.7alpha

Status

()

Core
CSS Parsing and Computation
P1
normal
VERIFIED FIXED
18 years ago
3 years ago

People

(Reporter: Alexander Larsson, Assigned: dbaron)

Tracking

({css2, testcase})

Trunk
mozilla1.7alpha
css2, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta3-] [patch], URL)

Attachments

(6 attachments, 7 obsolete attachments)

(Reporter)

Description

18 years ago
Given the rules:
   div { color: green; }
   a:hover + div { color: red;}

A <div> after an <a> doesn't turn red when the <a> is hovered.

But this rule works:
   a:hover div { color: red;}
A <div> inside an <a> turns red when the <a> is hovered.

Check out the URL for a complete example.
Summary: adjacent selector doesn't work with a :hover rule. → {css2} adjacent selector doesn't work with a :hover rule.
Here is a slightly more valid example:
   http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/pseudoselector.html
The problem also shows up with pseudo-elements. For example, the following two
rules have no effect:

   div:hover:after { content: "Hovering..."; }
   div:hover + div { background: navy; }

This is presumably something to do with :hover not triggering the right sort of
style context notification(?).

alla: good catch, BTW.

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: M15

Comment 2

18 years ago
Reassigning peterl's bugs to myself.

Comment 3

18 years ago
Accepting peterl's bugs that have a Target Milestone

Comment 4

18 years ago
Pushing my M15 bugs to M16
Keywords: css2
Migrating from {css2} to css2 keyword. The {css1}, {css2}, {css3} and {css-moz}
radars should now be considered deprecated in favour of keywords.
I am *really* sorry about the spam...

Updated

17 years ago
Summary: {css2} adjacent selector doesn't work with a :hover rule. → adjacent selector doesn't work with a :hover rule.

Updated

17 years ago
Target Milestone: M16 → M17
Summary: adjacent selector doesn't work with a :hover rule. → adjacent combinator doesn't work with a :hover rule.
*** Bug 39976 has been marked as a duplicate of this bug. ***
As per meeting with ChrisD today, taking QA.
QA Contact: chrisd → py8ieh=bugzilla
Pierre: I'd forgotten all about this bug -- it looks to me like we are simply
not generating the right reflow hints, but I have no idea really. Simple fix?
If not then lets move this off and deal with it next time -- but it would be
nice to get this fixed, since :hover is so popular with web authors.
Keywords: correctness, nsbeta3, testcase
OS: Linux → All
Priority: P3 → P5
Hardware: PC → All
Summary: adjacent combinator doesn't work with a :hover rule. → adjacent combinator doesn't work with a :hover rule [CASCADE]

Comment 9

17 years ago
Marking nsbeta3-. There are other more important nsbeta3+ bugs to work on.

Comment 10

17 years ago
Marking nsbeta3- this time.
Whiteboard: [nsbeta3-]

Comment 11

17 years ago
Block moved M17 bugs to mozilla0.9
Target Milestone: M17 → mozilla0.9

Updated

16 years ago
Target Milestone: mozilla0.9 → mozilla0.9.1

Comment 12

16 years ago
Moving to m0.9.2
Target Milestone: mozilla0.9.1 → mozilla0.9.2

Comment 13

16 years ago
Moving to m1.0
Target Milestone: mozilla0.9.2 → mozilla1.0

Updated

16 years ago
Target Milestone: mozilla1.0 → mozilla1.1
Bulk moving from Moz1.1 to future-P1. I will pull from this list when scheduling
work post Mozilla1.0.
Priority: P5 → P1
Target Milestone: mozilla1.1 → Future
(Assignee)

Comment 15

15 years ago
*** Bug 128040 has been marked as a duplicate of this bug. ***
*** Bug 132695 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

15 years ago
Summary: adjacent combinator doesn't work with a :hover rule [CASCADE] → adjacent combinator doesn't work with a :hover rule [SELECTORS-DYNAMIC]
related to bug 110972
(Assignee)

Comment 18

15 years ago
Created attachment 79158 [details]
testcase without :hover

There are really two different bugs here:  one that deals with all dynamic
style changes related to adjacent combinators, and one that deals with event
state changes and any selector where the event state is not on the target.  I'm
going to make this bug deal with the former since that's what I've always
assumed it was.  However, both fixes are necessary to fix the combination of
:hover and +.

This testcase, therefore, is a demonstration of problems with dynamic
reresolution and + that does not involve :hover.
(Assignee)

Comment 19

15 years ago
In particular, the bug I've always assumed this bug represented was that when we
get a dynamic change on an element, we call ReResolveStyleContext on that
element, but never its siblings (needed for +) or its parent (needed for :empty).

I filed the event state bug as bug 137395.
Summary: adjacent combinator doesn't work with a :hover rule [SELECTORS-DYNAMIC] → selectors with adjacent combinator missed by dynamic style reresolution [SELECTORS-DYNAMIC]
(Assignee)

Comment 20

15 years ago
Never mind the comments about there being another bug.  However, the more
general subject here still stands.
(Assignee)

Comment 21

15 years ago
http://www.hixie.ch/tests/adhoc/css/background/dynamic/001.html is also a
testcase for this bug.
I'm sure
   http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/pseudoselector.html
used to work better than it did (currently nothing happens at all).

Comment 23

15 years ago
cc'ing myself
Summary: selectors with adjacent combinator missed by dynamic style reresolution [SELECTORS-DYNAMIC] → selectors with adjacent combinator missed by dynamic style reresolution [SELECTORS-DYNAMIC] (:hover +)
(Assignee)

Comment 24

15 years ago
Assigning pierre's remaining Style System-related bugs to myself.
Assignee: pierre → dbaron
Status: ASSIGNED → NEW
(Assignee)

Comment 25

15 years ago
*** Bug 110972 has been marked as a duplicate of this bug. ***
I've been thinking a bit about this... The real problem is that we make this
assumption that when a node changes somehow (DOM manipulation, entering/leaving
:hover/:active/etc, and so forth) we need to re-resolve style only on it and its
descendants.  This is a decent assumption for CSS2, but most of the CSS3
selectors violate this assumption.... (as do counters and quotes).  We should
consider designing a new architecture to keep track of dynamic changes, imo.
(Assignee)

Updated

14 years ago
Summary: selectors with adjacent combinator missed by dynamic style reresolution [SELECTORS-DYNAMIC] (:hover +) → selectors with adjacent sibling combinator missed by dynamic style reresolution [SELECTORS-DYNAMIC] (:hover +)
(Assignee)

Comment 27

14 years ago
*** Bug 189309 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 28

14 years ago
One thought on how to handle this would be:
 1. Fix bug 163556
 2. Change Has[State|Attribute]DependentStyle to store and return whether there
are direct/indirect sibling combinators involved in any style changes.
 3. When adding/removing content, just reresolve style on the parent (to handle
empty, +, and all the new CSS3 variants).  (Perhaps there are good ways to
optimize this, but it might just not be that bad.)
Depends on: 163556

Comment 29

14 years ago
Created attachment 123523 [details]
Test-case with hover and active, on first element and last

Valid XHTML Strict and CSS example showing the problem with both a :hover and
:active pseudo class. Using the adjacent sibling selector, where the first
sibling has a pseudo class, the CSS is not applied. If the last sibling is the
one with a pseudo-class, it works as expected.
Hmm, Hixie (using: Mozilla 1.4b on Win2k, 2003050714) your example crashes the
browser with a "mozilla.exe has generated an error and will be closed by
Windows" message.

Nothing that explains the crash in any way is shown.
(Assignee)

Comment 31

14 years ago
Please keep one issue per bug (i.e, file separate bugs on any crashes).

Comment 32

14 years ago
I have created two more test-cases.

http://www.annevankesteren.nl/mozilla/bug/15608/index.xml
Type = text/xml

http://www.annevankesteren.nl/mozilla/bug/15608/index.html
Type = text/html

The xml test checks :hover and :not(:hover)
The html test check :hover, :not(:hover), :target and :focus

I know some of them are CSS3 selectors, but they could be used for futurre
reference.

Comment 33

14 years ago
Created attachment 128003 [details]
Testcase showing fickle ":hover + elem" workings
*** Bug 213304 has been marked as a duplicate of this bug. ***

Comment 35

14 years ago
*** Bug 213464 has been marked as a duplicate of this bug. ***

Comment 36

14 years ago
*** Bug 223672 has been marked as a duplicate of this bug. ***

Comment 37

14 years ago
Created attachment 137410 [details]
testcase showing *:hover + span {} sometimes working

A testcase using Mozilla 1.4 showing the *:hover pseudo class and adjacent
child selector intermittently working, depending on mouse movement.
(Assignee)

Comment 38

13 years ago
Created attachment 138240 [details] [diff] [review]
some work-in-progress
(Assignee)

Comment 39

13 years ago
Created attachment 138241 [details] [diff] [review]
some work-in-progress
Attachment #138240 - Attachment is obsolete: true
(Assignee)

Comment 40

13 years ago
Created attachment 138295 [details] [diff] [review]
patch
Attachment #138241 - Attachment is obsolete: true
(Assignee)

Comment 41

13 years ago
Comment on attachment 138295 [details] [diff] [review]
patch

This works for all the testcases in the bug, and I tested using a printf in
RestyleLaterSiblings that it wasn't being called when I didn't expect it to be
called (hovering and clicking UI, loading some bugzilla pages).
Attachment #138295 - Flags: superreview?(bz-vacation)
Attachment #138295 - Flags: review?(bz-vacation)
(Assignee)

Updated

13 years ago
Whiteboard: [nsbeta3-] → [nsbeta3-] [patch]
Target Milestone: Future → mozilla1.7alpha
(Assignee)

Comment 42

13 years ago
Comment on attachment 138295 [details] [diff] [review]
patch

I already noticed the two occurrences of bad indentation of the |mHint| member
variable in nsStyleSet.cpp.

Also, is putting the new enum in nsChangeHint.h too evil?  Should I make a new
header file just for it?
(Assignee)

Comment 43

13 years ago
(Note that this patch does not fix bug 73586, bug 98997, or bug 229915.  All
three of those bug would be fixed by step 3 of comment 28, but I'm not sure if
that's the best approach.)
(Assignee)

Comment 44

13 years ago
Comment on attachment 138295 [details] [diff] [review]
patch

Never mind.  This patch causes a bunch of weird things...
Attachment #138295 - Attachment is obsolete: true
Attachment #138295 - Flags: superreview?(bz-vacation)
Attachment #138295 - Flags: review?(bz-vacation)
(Assignee)

Comment 45

13 years ago
The problems are fixed by backing out the changes to
nsCSSFrameConstructor::AttributeChanged .
(Assignee)

Comment 46

13 years ago
Created attachment 138305 [details] [diff] [review]
patch

The mistake in the previous patch was putting
    // put primary frame on list to deal with, re-resolve may update or add
next in flows
    changeList.AppendChange(primaryFrame, aContent, hint);
inside an |if (rshint & eReStyle_Self)| test.
(Assignee)

Updated

13 years ago
Attachment #138305 - Flags: superreview?(bz-vacation)
Attachment #138305 - Flags: review?(bz-vacation)
(Assignee)

Comment 47

13 years ago
I could probably remove the enumeration halting code from WalkRuleProcessors. 
And I should probably wait until bryner lands bug 64116 before landing.
(Assignee)

Comment 48

13 years ago
Created attachment 138575 [details] [diff] [review]
patch

merged with bryner's changes for bug 64116
Attachment #138305 - Attachment is obsolete: true
(Assignee)

Comment 49

13 years ago
Created attachment 138576 [details] [diff] [review]
patch

with the changes to nsStyleSet::WalkRuleProcessors as well...
Attachment #138575 - Attachment is obsolete: true
(Assignee)

Updated

13 years ago
Attachment #138305 - Flags: superreview?(bz-vacation)
Attachment #138305 - Flags: review?(bz-vacation)
(Assignee)

Updated

13 years ago
Attachment #138576 - Flags: superreview?(bz-vacation)
Attachment #138576 - Flags: review?(bz-vacation)
Comment on attachment 138576 [details] [diff] [review]
patch

>Index: content/html/style/src/nsCSSStyleSheet.cpp
> CSSRuleProcessor::HasAttributeDependentStyle(AttributeRuleProcessorData* aData,
>   // XXX What about XLinks?

If we kept track of the attr namespace, not just its name, we could do a
restyleSelf on any change of an attr in the xlink namespace.... ;)

>Index: content/shared/public/nsChangeHint.h
>+enum nsReStyleHint {
>+  eReStyle_Self = 0x1,
>+  eReStyle_LaterSiblings = 0x2
>+};

Is it really better to use nsRestyleHint(0) all over instead of having a name
for it here?  I know your feelings on the matter, and I'm ok either way, I
guess.	It's just that looking at code like nsRestyleHint(0) always leaves me
asking "what does 0 mean"?

At the very least, comment here that 0 means no restyling necessary.

>Index: layout/html/style/src/nsCSSFrameConstructor.cpp
>+void
>+nsCSSFrameConstructor::RestyleLaterSiblings(nsIPresContext *aPresContext,

Perhaps this should return at least whether it reconstructed the whole doc?  If
that happens, caller knows it needs to do nothing else.

>+    if (primaryFrame) {
...
>+      // no frames, reconstruct for content
>+      MaybeRecreateFramesForContent(aPresContext, child);

This chunk of code appears in a whole bunch of places, nearly identically. 
With the patch in bug 214013 it'll become completely identical.  Maybe it
should have its own separate function?	Again, one that returns whether it
reconstructed the doc, I guess.

> nsCSSFrameConstructor::ContentStatesChanged(nsIPresContext* aPresContext, 
>+  DoContentStateChanged(aPresContext, aContent1, aStateMask);
>+  return DoContentStateChanged(aPresContext, aContent2, aStateMask);

Do we want to somehow keep the optimization where if the two are ancestor and
descendant we only reresolve style on the ancestor?  That's a valid
optimization to make here (it doesn't matter whether the kids sibling's would
have to be reresolved; reresolving an ancestor will reresolve them anyway). 
Same for the case when aContent1 == aContent2.	Or do these cases get hit so
rarely it's not worth it?

>+nsCSSFrameConstructor::DoContentStateChanged(nsIPresContext* aPresContext, 
>+      if (primaryFrame) {
>+        PRUint8 app = primaryFrame->GetStyleDisplay()->mAppearance;

Um... This is coming after you processed the changelist.  If the hint for this
frame was ReconstructDoc/Frame, you really don't want to be touching it here, I
would think

As a matter of fact, I would probably put this block up in the "else" clause
above, maybe even before I ProcessRestyledFrames.

I like the clarity cleanup here, btw.

> nsCSSFrameConstructor::AttributeChanged(nsIPresContext* aPresContext,

>+    if (hint & nsChangeHint_ReconstructDoc) {
>+      result = ReconstructDocElementHierarchy(aPresContext);
>+      changeList.Clear();

Make that a |return ReconstructDocElementHierarchy(aPresContext);|

> nsCSSFrameConstructor::RecreateFramesForContent(nsIPresContext* aPresContext,

>+  // Rebuilding the frame tree can have bad effects, especially if it's the
>+  // frame tree for chrome (see bug 157322).
>   nsCOMPtr<nsIDocument> doc = aContent->GetDocument();
>   NS_ENSURE_TRUE(doc, NS_ERROR_FAILURE);

Hey, as long as you're here, how about:

  NS_ENSURE_TRUE(aContent->GetDocument(), NS_ERROR_FAILURE);

?  "doc" is unused below.
(Assignee)

Comment 51

13 years ago
> Perhaps this should return at least whether it reconstructed the whole doc?  If
> that happens, caller knows it needs to do nothing else.

None of the callers do anything else after calling it, so it doesn't seem worth it.

> Maybe it should have its own separate function?

Once bug 214013 lands.

> Do we want to somehow keep the optimization where if the two are ancestor and
> descendant we only reresolve style on the ancestor?

I don't think it's worth it.  It's a very rare case, and the code is complicated
enough.  (The optimization currently in the tree is wrong, since it's done
before the HasStateDependentStyle calls.)
(Assignee)

Comment 52

13 years ago
> As a matter of fact, I would probably put this block up in the "else" clause
> above, maybe even before I ProcessRestyledFrames.

I put it before the HasStateDependentStyle call instead.  This should be done
even if HasStateDependentStyle doesn't say there's state-dependent style.
(Assignee)

Comment 53

13 years ago
Created attachment 138982 [details] [diff] [review]
patch

Addresses the comments not addressed in comment 51 (with one as described in
comment 52).
Attachment #138576 - Attachment is obsolete: true
(Assignee)

Updated

13 years ago
Attachment #138576 - Flags: superreview?(bz-vacation)
Attachment #138576 - Flags: review?(bz-vacation)
(Assignee)

Updated

13 years ago
Attachment #138982 - Flags: superreview?(bz-vacation)
Attachment #138982 - Flags: review?(bz-vacation)
> None of the callers do anything else after calling it, so it doesn't seem worth
> it.

The exception is the second DoContentStatesChanged call (which could maybe be
skipped).  Probably not worth it.

>>+    if (hint & nsChangeHint_ReconstructDoc) {
>>+      result = ReconstructDocElementHierarchy(aPresContext);
>>+      changeList.Clear();
>Make that a |return ReconstructDocElementHierarchy(aPresContext);|

You didn't do this part.
Comment on attachment 138982 [details] [diff] [review]
patch

With that one change (to return if the whole thing is reconstructed in
AttributeChanged), r+sr=bzbarsky
Attachment #138982 - Flags: superreview?(bz-vacation)
Attachment #138982 - Flags: superreview+
Attachment #138982 - Flags: review?(bz-vacation)
Attachment #138982 - Flags: review+
(Assignee)

Comment 56

13 years ago
Created attachment 138984 [details] [diff] [review]
patch

oops
Attachment #138982 - Attachment is obsolete: true
(Assignee)

Comment 57

13 years ago
Fix checked in to trunk, 2004-01-13 17:36 -0800.

See also additional bugs mentioned in comment 43.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED

Comment 58

13 years ago
v 20030114 PC/WinXP
Status: RESOLVED → VERIFIED
Created attachment 139114 [details]
Testcase with input display none and label form attribute and adjacent dynamic stylerule.

The patch works great afaik.
However, in this testcase I does not work well.
I use input {display:none;} and input:checked+label{background-color:green;}
Please file a new bug on that testcase, with something resembling steps to
reproduce (and cc me and dbaron).
(Assignee)

Comment 61

13 years ago
comment 59 is now bug 231081.
(Assignee)

Comment 62

13 years ago
*** Bug 232694 has been marked as a duplicate of this bug. ***

Comment 63

13 years ago
(In reply to comment #62)
> *** Bug 232694 has been marked as a duplicate of this bug. ***

Sorry for the duplicate! My misstake.

I tried the nigthly build, dated 2004-01-30 and it works perfectly!

Fantastic work! I'm very happy! Thank you folks so very much! Thank you. Keep on
the great work. 
You need to log in before you can comment on or make changes to this bug.