User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:7.0a1) Gecko/20110627 Firefox/7.0a1 Build ID: 20110627030739 Steps to reproduce: Visit https://eyeasme.com/Joe/MathML/MathML_text_decoration_bug click on a formula to see the code that generated it then, return to original page to see that the formulas are only partially correctly colored between "visited" and "unvisited" link colors Actual results: Linked MathML formulas do not correctly show "visited" and "unvisited" colors. Expected results: Linked MathML formulas should display correct colors when visited.

The MathML formulas are all hyper-linked and have been visited. Notice how the formulas are displayed with a combination of the visited and unvisited colors. The image was made with Nightly build 7.0a1 (2011-06-27)

The problem seems to happens with <mo> and other graphical components (such as the frac bar).

Fred, are there cases in which MathML manually resolves style contexts for <mo> and the like? If so, where is that code?

I think it is in layout/mathml/nsMathMLmoFrame.cpp, nsMathMLmoFrame::GetAdditionalStyleContext There is a particularity of <mo>'s: they are sometimes stretchy characters and so use a specific drawing module in layout/mathml/nsMathMLChar.cpp. This can explain why they are rendered differently.

OK. So we're talking about nsMathMLFrame::ResolveMathMLCharStyle here, right?

OK, I have a fix; just need to write some tests.

Great. Does it fix the style issue only for nsMathMLChars? Or does it also work for the graphical components of mfrac, menclose, radicals etc?

(In reply to comment #8) > Great. Does it fix the style issue only for nsMathMLChars? Or does it also > work for the graphical components of mfrac, menclose, radicals etc? OK, the patch you just posted seems to indicate it does take graphical component into account.

I think I got everything. I believe the test in the patch tests chars, mfrac, and radicals. I believe the test does NOT test menclose because I had no idea how to test it. Suggestions on what Mathml would exercise that welcome.

You can replace the <msrqt> by <menclose notation="radical circle roundedbox updiagonalstrike downdiagonalstrike"> Also you should now be able to use <math href=""> instead of a <a> element. mode="display" is deprecated, you may use display="block" instead. http://www.w3.org/TR/MathML/chapter2.html#interf.toplevel

A <mfrac bevelled="true"> should also enable you to test the nsDisplayMathMLSlash.

> <menclose notation="radical circle roundedbox updiagonalstrike > downdiagonalstrike"> Did that in the denominator. > Also you should now be able to use <math href=""> instead of a <a> element. Done. > mode="display" is deprecated, you may use display="block" instead. Done. > A <mfrac bevelled="true"> should also enable you to test the > nsDisplayMathMLSlash. Added.

BTW, we have a similar problem in bug 487587, where the <mo>'s use specific code to determined whether they are selected in nsMathMLmoFrame::IsFrameInSelection. However that code does not seem correct because it always claims that the frame is not selected. I've tried to write a patch removing the code involved, but in that case the <mo>'s are sometimes displayed selected whereas they are not. I would appreciate if some Gecko peers could indicate what is the correct way to determine that an mo frame is selected.

(In reply to Boris Zbarsky (:bz) from comment #14) > Created attachment 542871 [details] [diff] [review] > Updated fix Patch became bit rotten after http://hg.mozilla.org/mozilla-central/rev/8f20dc5f4c8f

Works fine if you tell it to ignore a few lines of context (e.g. qpushed just fine over hear).

Comment on attachment 542871 [details] [diff] [review] Updated fix r=dbaron, except you'll need to run the reftest in layout/style/test/test_visited_reftests rather than from the reftest harness if you want it to pass reliably (due to async link coloring). You should probably make it a mathml-named test in the css-visited reftests directory to match.

Good catch. Will do.