linked MathML formulas fail to correctly display visited and unvisited colors

RESOLVED FIXED in mozilla10

Status

()

Core
MathML
P2
normal
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: Joe Java, Assigned: bz)

Tracking

Trunk
mozilla10
All
Other
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

6 years ago
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.
(Reporter)

Comment 1

6 years ago
Created attachment 542437 [details]
screen shot of reference page after linkes have been 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).
Status: UNCONFIRMED → NEW
Component: General → MathML
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → mathml
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.
Assignee: nobody → bzbarsky
Priority: -- → P2
Created attachment 542862 [details] [diff] [review]
Fix
Whiteboard: [need review]
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.
Attachment #542862 - Attachment description: dbaron → Fix
Attachment #542862 - Flags: review?(dbaron)
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.
Created attachment 542871 [details] [diff] [review]
Updated fix
Attachment #542871 - Flags: review?(fred.wang)
Attachment #542871 - Flags: review?(dbaron)
Attachment #542862 - Attachment is obsolete: true
Attachment #542862 - Flags: review?(dbaron)
Attachment #542871 - Flags: review?(fred.wang) → review+
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.
Attachment #542871 - Flags: review?(dbaron) → review+
Good catch.  Will do.
http://hg.mozilla.org/integration/mozilla-inbound/rev/ff353339df3e
Flags: in-testsuite+
Whiteboard: [need review]
Target Milestone: --- → mozilla10
https://hg.mozilla.org/mozilla-central/rev/ff353339df3e
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.