Bug 55255

Summary:

background-color misbehaving for :link versus :visited

Product:

WebKit

Reporter:

Mike Capp <mike.capp>

Component:

CSS

Assignee:

Nobody <webkit-unassigned>

Status:

RESOLVED CONFIGURATION CHANGED

Severity:

Normal

CC:

bfulgham, brkemper, haraken, hyatt, kling, koivisto, mitz, morrita, tonikitoo

Priority:

Version:

528+ (Nightly build)

Hardware:

All

OS:

All

Attachments:

Description	Flags
Reduction	none
Patch	koivisto: review-
Shows incorrect coloring of child of "A" link.	none

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-	Details Formatted Diff Diff
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

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.