Bug 5983

Summary: REGRESSION: onmouseover-powered navbar at MacNN renders incorrectly
Product: WebKit Reporter: Jon <jon>
Component: DOMAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Major CC: alice.barraclough, timothy
Priority: P1 Keywords: InRadar
Version: 420+   
Hardware: Mac   
OS: OS X 10.4   
URL: http://www.macnn.com/
Attachments:
Description Flags
Reduced testcase
none
Update hover info when a renderer goes away darin: review+

Jon
Reported 2005-12-06 16:37:53 PST
MacNN's new front page features a JS powered navbar. In Safari 2.0.2 (416.13), it renders correctly, with the moused-over sections changing graphics while the other sections remain in their non-moused-over state. However, in TOT powered Safari, once a section has been moused over it remains depressed until the user mouses over the next section in line, which returns the previous section to its un-moused-down state. However, once the user moves to a third section, the first section returns to its mouseover state. Eventually, by scrubbing up and down the navbar, all the sections will retain their mouseover state except the one immediately before (direction dependent) the currently moused over section. When no section is moused over (after all have been moused over at least once) all of the sections will retain their moused over state. I'm not sure that's very clear, but the behavior is obvious when you visit the site and try to use the navbar.
Attachments
Reduced testcase (353 bytes, text/html)
2006-01-19 15:56 PST, mitz 		no flags
Details
Update hover info when a renderer goes away (8.38 KB, patch)
2006-01-20 09:06 PST, mitz 		darin: review+
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
mitz
Comment 1 2006-01-06 01:04:12 PST
The regression happened before 2005-10-01 according to nightly builds, and it (or some version of it) is already present in WebKit-417.9
Alice Liu
Comment 2 2006-01-09 16:46:02 PST
<rdar://problem/4403730>
Geoffrey Garen
Comment 3 2006-01-17 12:02:58 PST
I can't repro with the latest sources. Can anyone else?
Darin Adler
Comment 4 2006-01-18 09:20:25 PST
I also can't reproduce. Did the site change? We probably need to close this bug.
Alexey Proskuryakov
Comment 5 2006-01-18 11:03:58 PST
I cannot reproduce this with WebKit-CVS-2005-12-14 20-06-29 GMT. Apparently, the site has indeed changed.
Joost de Valk (AlthA)
Comment 6 2006-01-19 10:11:09 PST
Me neither, closing this, no use to all look at it :)
Joost de Valk (AlthA)
Comment 7 2006-01-19 10:14:18 PST
Removing NeedsReduction. Alice, don't know if you want to remove the "InRadar" too?
mitz
Comment 8 2006-01-19 13:51:10 PST
(In reply to comment #4) > I also can't reproduce. Did the site change? I can't reproduce on the site either, but a copy I made of the site on Jan 4 (and slightly reduced) still looks buggy. Since this bug is a regression and the site always worked in Firefox, I think it's important to look at it. It's very likely that the site was changed soon after WebKit 417.9 was released, since the release contained this regression.
mitz
Comment 9 2006-01-19 15:56:43 PST
Created attachment 5788 [details] Reduced testcase When an element changes to display:none, it maintains (some?) of its hover state (and doesn't call its onmouseout handler). I think this is a regression from the 2005-07-29 checkin that changed :hover and :active behavior.
Joost de Valk (AlthA)
Comment 10 2006-01-20 01:07:53 PST
Good testcase Mitz! Upping severity to Major and changing NeedsReduction to HasReduction.
Joost de Valk (AlthA)
Comment 11 2006-01-20 01:09:10 PST
And forget to add regression keyword.
mitz
Comment 12 2006-01-20 09:06:31 PST
Created attachment 5801 [details] Update hover info when a renderer goes away
Darin Adler
Comment 13 2006-01-21 10:58:05 PST
Comment on attachment 5801 [details] Update hover info when a renderer goes away Looks great, r=me.
Joost de Valk (AlthA)
Comment 14 2006-01-22 04:52:24 PST
Removing keyword(s) cause bug is closed.
Note You need to log in before you can comment on or make changes to this bug.