176448 - Nested anchors spanning a table don't both erase :hover style when mouse moved slowly

Status: RESOLVED WORKSFORME

(Core :: CSS Parsing and Computation, defect)

Description

[Drew Edwards]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2b) Gecko/20021023
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2b) Gecko/20021023

In the bbs pages at http://trekbbs.com, when the page is scrolled with the
scrollbar arrow or using the thumb the page scrolls correctly. That is, lines do
not incorrectly display under the topics. When scrolled with a mouse wheel (in
test case: any Logitech mouse), lines appear and remain static until the window
is  refreshed. This problem does not appear in Mozilla 1.1.

Reproducible: Always

Steps to Reproduce:
1.Go to http://www.trekbbs.com
2.Scroll the forum list with a mousewheel.
3.See lines that shouldn't appear.
4.Refresh screen and repeat by scrolling with scrollbar.
5.See *correctly* drawn forum list.

Actual Results:  
As text comes into view during a mouse scroll it appears underlined.

Expected Results:  
Text should not be underlining as it scrolls into view. Mozilla exhibits correct
behavior when scrolling is done with scrollbar. In the past Mozilla did not
exhibit this behavior.

Bug is theme independant.

Comment 1

[Kurt Weinschenker]

More than just scrolling with a mousewheel, methinks.

Tested with Mozilla trunk build 2002102308, running on an iMac DV G3/400 under
Mac OS  9.2.2. and QT 6.0.2.

When I simply *mouse over* the page indicated, static lines appear as I mouse
over the topic titles.  They stay there until the page is refreshed.

I'm using the Apple USB Mouse plugged into the Apple USB Keyboard which was
included as standard on this series of iMac.

Needless to say, this should not happen.

Comment 2

[Drew Edwards]

The scroll wheel-specific drawing bug appears fixed in the 20021104 nightly.

Comment 3

[Drew Edwards]

While not part of the original bug report, the behavior Kurt Weinschenker
references regarding mouse over behavior at the same test site still occurs in
the Nov 4th MacOS X Nightly.

Comment 4

[Greg K.]

WorksForMe using FizzillaCFM/2002103011 on 10.1.5.

Comment 5

[Greg K.]

Drew, please attach a screenshot of the problem.

Comment 6

[Drew Edwards]

Attachment: Attachment showing "sticking" underlined links after mouseovers as requested

Screenshot from http://www.trekbbs.com exhibiting the "mouse over" bug. When
the cursor passes over a link on the site the link improperly continues to
display an underline. Tested with MacOS X nightly 20021104.

This is a different bug from the scrollwheel drawing bug behavior. The
scrollwheel issue is fixed in this nightly.

Comment 7

[Drew Edwards]

Attachment: At site, mouse over a link and all text on the page is underlined!

The new screenshot shows what happens at http://www.trekbbs.com when a mouse
pointer rolls over a link or really any part of the page. Refreshing clears the
excess lines as does moving the mouse pointer out of the page area (i.e. over
the tabs, or toolbars). Tested with 14 Nov Mac OS X Nightly on Mac OS X.2.2.

I checked with the Windows Mozilla nightly and it does not exhibit any problems
with the test site, FWIW.

Comment 8

[Greg K.]

Confirmed using FizzillaCFM/2002110808 on 10.1.5. The problem is nested anchors
not all being fired onmouseout by Mozilla when the mouse is moved slowly off the
text. Testcase coming.

Comment 9

[Greg K.]

Attachment: Minimized testcase

Comment 10

[Greg K.]

Reassigning to Event Handling.

Comment 11

[Greg K.]

Actually, I suppose this isn't necessarily Event Handling, since it's :hover
resolution rather than onmouseout we're talking about. Reassigning to Style
System first.

Comment 12

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

You see this even when the mouse isn't next to the table (which we're
considering within the a)?  We're considering the region covered by the A to be
block-like over the area where it contains a block, and we're not letting the
color inherit into the table in quirks mode.

Comment 13

[Greg K.]

Attachment: Revised testcase

I see this when I mouse onto the text, then slowly mouse down off it. The text
returns to black, but the red underline remains.

If I change it to Standards mode, then the text also remains red when I mouse
off it.

If I change the outer anchor to display: block, then it works correctly; that
is, the :hover underline does disappear when the outer anchor is moused off.

Comment 14

[Greg K.]

(FWIW, if this is a bug, it was introduced between 1.2a (2002091014) and
2002100308.)

Comment 15

[Boris Zbarsky [:bzbarsky]]

This is working fine for me, win2k 1.3a build.  The changes in bug 146409 
should have fixed this bug...

Could people who actually saw this retest with a recent (newer than 2002-11-11) 
trunk build, please?

Comment 16

[Greg K.]

Appears to be fixed using FizzillaMach/2002122307.

Comment 17

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

I see a bunch of weird effects in a 1.2.1 build but don't see them in a trunk
build from a few days ago (on Linux).  Marking worksforme.