202917 - [FIX]CSS anchors move when mouse overing them

Status: RESOLVED FIXED

(Core :: Layout: Block and Inline, defect, P1)

Description

[Olivier Cahagne]

build ID: 2003042208 on Linux.

I don't think this is bug as I've never seen before on this page and I usually
look at it everyday. 20030421 build doesn't exhibit this problem.

Steps to reproduce:
1. Load http://www.nitot.com/standards/blog/
2. Mouse over a blog link, say 'nous indique" in April 22nd post at 3:12,
3. See the 'nous indique' being duplicated and moving at the beginning of the
sentence.

Comment 1

[Olivier Cahagne]

I meant "I don't think this is bug 177539" (unless the blog code also changed
between yesterday and today).

Comment 2

[Olivier Cahagne]

Attachment: Screenshot showing the modified link

Comment 3

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

Regression between 2003-04-21-12-trunk and 2003-04-21-22-trunk.

Comment 4

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

bz touched nsCSSFrameConstructor multiple times yesterday, so I blame him. :-)

Comment 5

[Boris Zbarsky [:bzbarsky]]

Looking.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Backing out the bug 145425 checkin fixes the problem...  Looking into what's up
with it now.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Attachment: patch

Oh, fun.  ;) So I switched the GetAfterFrame/GetBeforeFrame impls from doing
"get the last/first child and return it if it's a pseudo-frame" to "get the
last/first child and return it if it matches the before/after pseudo".	All
well and good... but on this page we have the following CSS:

a:after { content: something, color: gray }
a:hover { color: white }

So hovering the a will reresolve style.  When it does so, it walks the child
frames and reresolves them.  Now when reresolving the child :after frame, we
check whether the content node is an element (it is -- it's the <a>).  Then we
check whether there is :after style for that content node -- there is.	Then we
check whether there is an :after frame as a child of the :after frame(!).  This
used to return true, since it would find one of the pseudo text frames.  So
nothing would happen.  With my change from yesterday, there is no :after frame
returned, so we enque a reframe hint targeted at the :after frame and the <a>
content.  When this reframe happens, we try to insert the new frame for the <a>
as a sibling of the prevSibling of the :after frame, which asserts about not
finding prevSibling in the block's child list, etc.

Anyway, the proposed fix is to skip the check for :before/:after frames when
reresolving a pseudo style context....	I _think_ that pseudos cannot have
:before and :after content.

If that is incorrect, I'll look for a different way to do this...

Comment 8

[Boris Zbarsky [:bzbarsky]]

Taking.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Fixed.  Olivier, thanks for catching this!

Comment 10

[Olivier Cahagne]

Boris, thanks for fixing this so quickly, you didn't even leave enough time to
produce a reduced testcase ! :)