User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20100101 Firefox/21.0 Build ID: 20130430204233 Steps to reproduce: Given the following HTML: <a href="//example.com">example.com</a> Given the following CSS: a { -webkit-transition: all 0.4s ease-out; -moz-transition: all 0.4s ease-out; -ms-transition: all 0.4s ease-out; -o-transition: all 0.4s ease-out; transition: all 0.4s ease-out; color: #06c; text-decoration: none; border-bottom: 1px solid transparent; } a:hover, a:focus { border-bottom-color: #06c; } a:visited { color: #613eb0; } a:visited:hover, a:visited:focus { border-bottom-color: #613eb0; } Actual results: After visiting the target of the anchor the :visited style is applied correctly. Upon hovering over the visited link Firefox first transitions to the blue (declared earlier) and then to the purple (declared last). Expected results: Same behavior as seen in Google Chrome. The later declaration has to overwrite the previous one. Additionally the :visited:hover and :visited:focus should not even be necessary for this to work correctly (again, as in Google Chrome).

Oh, forgot to mention. The behavior is consistent along all browsers (not only Google Chrome). I tested it with the latest versions of Internet Explorer, Opera Desktop and even the old Apple Safari for Windows.

Sounds like a possible issue with the dual visited/unvisited style contexts both transitioning...

I can also confirm this bug. You can see it on my webpage (http://niewiarowski.it). Opera, Chrome and the others rendering this correctly, but Fx 22.0a2 (and oldest) - not. Color animating to :link color, and next insantly moves to :visited color.

I also can confirm this, by this testcase. :visited anchor animates the : link behavior instead of :visited behavior.

Just discovered this bug. It is still present in FF 43.0.4.

I can also confirm this bug (FF 49.0). Test case example: CSS: a{ font-size:50px; color:gray; font-weight:1000; transition:color 1s; } a:hover{ color:black; } a:visited{ color:lightgray; } HTML: <a href="">VISITED LINK</a><br> <a href="https://google.com/randomtext">LINK NOT VISITED</a>

30.05.2017, still can reproduce this bug. Can I get any report or info, how soon would it be fixed?

Stylo builds seem a little closer to the desired result, but it still transitions out using the unvisited (blue) style. Adding jryans since he knows how :visited works in Stylo.

Interesting, thanks for pointing me to this bug. When I initially added :visited support in Stylo, I did some limited testing with transitions and animations, and it appeared at the time that it wasn't expected to work, but perhaps this existing bug led me astray. I left comments in a few spots related to animations and transitions[1] noting that they don't yet attempt to do anything with visited styles in Stylo. :birtles, I don't know the animations / transition code paths very well. Does it seem like missing visited data from the paths I commented[1] would cause the behavior we're currently getting under Stylo? (As with anything :visited related, there's always the privacy aspect to consider. So far, it seems safe to add this support to me, as we can use the same "relevant link" decision making that's used elsewhere. Also, these test cases appear to work in other browsers with similar protections.) [1]: http://searchfox.org/mozilla-central/search?q=ignores%20visited&case=true&path=

(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #10) > Interesting, thanks for pointing me to this bug. > > When I initially added :visited support in Stylo, I did some limited testing > with transitions and animations, and it appeared at the time that it wasn't > expected to work, but perhaps this existing bug led me astray. > > I left comments in a few spots related to animations and transitions[1] > noting that they don't yet attempt to do anything with visited styles in > Stylo. > > :birtles, I don't know the animations / transition code paths very well. > Does it seem like missing visited data from the paths I commented[1] would > cause the behavior we're currently getting under Stylo? Sorry for the delay. Yes, that seems likely. Of the four: a. compute_style_for_animation_step in servo/components/style/animation.rs - Not used in Stylo (Servo only). b. get_after_change_style in servo/components/style/matching.rs - Used in Stylo for transitions. c. get_base_style in servo/components/style/matching.rs - Used in Stylo, but only for SMIL and additive animations, I believe. d. compute_for_declarations in servo/components/style/stylist.rs - Used in Stylo, but only for <canvas>, I believe. So, of the four (b) is the one that seems to be related. From the visual result, it seems like the before-change style is also wrong, but I haven't debugged this to find out if that's the case or not.

Clearly ni on Jet as he no longer works at Mozilla.