RESOLVED CONFIGURATION CHANGED 55255
background-color misbehaving for :link versus :visited 
https://bugs.webkit.org/show_bug.cgi?id=55255
Summary background-color misbehaving for :link versus :visited
Mike Capp
Reported 2011-02-25 13:42:14 PST
Created attachment 83869 [details] Reduction Safari 5.0.3 (Mac OS 10.5.8) - FAIL Chrome 9.0.597.98 (Windows 2003 Server) - FAIL Firefox - OK IE7 - OK Opera - OK The attached reduction declares one CSS rule - "a:link { background-color:#bfb; }" - and contains two hyperlinks. Click on the "Visited Link" one to ensure that it's really visited; go back if necessary. EXPECTED RESULT: per my reading of http://www.w3.org/TR/CSS/selector.html#link-pseudo-classes :link and :visited are mutually exclusive, so only "Unvisited Link" should have a pale green background. "Visited Link" should show the UA defaults for visited links, probably purple on white/transparent. ACTUAL RESULT: "Unvisited Link" does have a pale green background. "Visited Link" shows the default color purple, which is good, but has a background-color of black, which isn't. Web Inspector in both Safari and Chrome reflects internal confusion - Computed Style shows a black background, but below that the a:link pale green rule is shown as applying. This issue was originally raised at http://code.google.com/p/chromium/issues/detail?id=44043 - I'll leave a comment pointing here.
Attachments
Reduction (329 bytes, text/html)
2011-02-25 13:42 PST, Mike Capp 		no flags
Details
Patch (25.37 KB, patch)
2011-08-08 22:01 PDT, Kentaro Hara 		koivisto: review-
DetailsFormatted DiffDiff
Shows incorrect coloring of child of "A" link. (570 bytes, text/html)
2011-10-21 11:25 PDT, Brad 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Kentaro Hara
Comment 1 2011-08-08 22:01:06 PDT
Created attachment 103330 [details] Patch
Kentaro Hara
Comment 2 2011-08-08 22:07:01 PDT
I confirmed that this bug happens on Mac Safari 5.0.5, Mac Chromium 12.0.742.112, and Linux Chromium 13.0.782.56.
Hajime Morrita
Comment 3 2011-08-09 18:15:00 PDT
(In reply to comment #2) > I confirmed that this bug happens on Mac Safari 5.0.5, Mac Chromium 12.0.742.112, and Linux Chromium 13.0.782.56. Could you update your patch? it looks conflicting against ToT. Tips: Don't append skip entry at the bottom of file - it conflicts often. You can insert the line somewhere more relevant place to avoid it.
Hajime Morrita
Comment 4 2011-08-09 18:23:41 PDT
Comment on attachment 103330 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=103330&action=review > LayoutTests/fast/history/visited-link-default-background-color.html:1 > +<html> Is it possible to convert this to a text-based test using window.getComputedStyle() ?
Andreas Kling
Comment 5 2011-10-19 06:50:12 PDT
Comment on attachment 103330 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=103330&action=review > LayoutTests/fast/history/visited-link-default-background-color.html:17 > +<iframe src="resources/dummy.html" style="display:none"></iframe> > +<p><a href="resources/dummy.html">This text should be on a white background.</a></p> If you just need it to match :visited, you can use <a href=""> which is much simpler.
Brad
Comment 6 2011-10-21 11:23:55 PDT
There is also a new behavior now (not certain if it is a separate bug or not). If I have a span inside an anchor ("A" element), it's color is ignored when the anchor becomes visited.
Brad
Comment 7 2011-10-21 11:25:24 PDT
Created attachment 111993 [details] Shows incorrect coloring of child of "A" link. There is also a new behavior now (not certain if it is a separate bug or not). If I have a span inside an anchor ("A" element), it's color is ignored when the anchor becomes visited. See well-reduced attachment.
Antti Koivisto
Comment 8 2011-10-23 06:31:29 PDT
Comment on attachment 103330 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=103330&action=review r- for bad test results. You will also need to explain why this is a progression. >> LayoutTests/fast/history/visited-link-default-background-color.html:17 >> +<p><a href="resources/dummy.html">This text should be on a white background.</a></p> > > If you just need it to match :visited, you can use <a href=""> which is much simpler. Use <a href="">, that is guaranteed to match visited on all platforms. > LayoutTests/platform/mac/fast/history/visited-link-default-background-color-expected.txt:13 > + RenderInline {A} at (0,0) size 273x18 [color=#0000EE] [bgcolor=#808000] > + RenderText {#text} at (0,0) size 273x18 > + text run at (0,0) width 273: "This text should be on a white background." This test result is wrong. The background is not white. > Source/WebCore/rendering/style/RenderStyle.cpp:-1192 > - // FIXME: Technically someone could explicitly specify the color transparent, but for now we'll just > - // assume that if the background color is transparent that it wasn't set. Note that it's weird that > - // we're returning unvisited info for a visited link, but given our restriction that the alpha values > - // have to match, it makes more sense to return the unvisited background color if specified than it > - // does to return black. This behavior matches what Firefox 4 does as well. Why is this a good change? The comment says that the current behavior matches Firefox.
Antti Koivisto
Comment 9 2011-10-23 06:35:55 PDT
(In reply to comment #6) > There is also a new behavior now (not certain if it is a separate bug or not). If I have a span inside an anchor ("A" element), it's color is ignored when the anchor becomes visited. This belongs to a separate bug (likely a dupe of bug 70470).
Brent Fulgham
Comment 10 2022-07-12 14:23:08 PDT
Safari, Chrome, and Firefox all agree on rendering for this test case. I don't believe there is any remaining compatibility issue.
Note You need to log in before you can comment on or make changes to this bug.