steps to reproduce: 1. visit http://placenamehere.com/article/402/ProgressiveEnhancementForBetterPerformance 2. click on a link 3. go back to http://placenamehere.com/article/402/ProgressiveEnhancementForBetterPerformance Notice that the link you visited now shows up with a black background.
Seems likely this is somehow fallout from visited link privacy, but it's hard to tell definiteively.
I cannot reproduce this with r76045. Could you please check if this still happens for you?
(In reply to comment #2) > I cannot reproduce this with r76045. Could you please check if this still happens for you? I can reproduce it with the latest nightly, though not with http://placenamehere.com/article/402/ProgressiveEnhancementForBetterPerformance/ any longer. I'm running a workspace build now to check against the latest trunk. The pages I can reproduce it with are unfortunately not public ones; they are pages at the W3C site that require authentication. But Maciej does have access to them; for example: http://www.w3.org/2002/09/wbs/44061/20080526_media-requirements/ I've been trying to put together a reduction from that to demonstrate the bug but have not been able to so far. Maciej, in the mean time if you can re-confirm this by checking at that WBS URL above, please change the status back.
I can see it, too. Confirmed with r75996, not a regression from Safari 5.
Created attachment 79605 [details] reduced test case This is weird, the problem occurs with just a single rule: a:link { background:#eee; }
<rdar://problem/8892367>
Created attachment 88489 [details] Patch
Created attachment 88493 [details] Patch
Fixed in r83087.