Last Comment Bug 559042 - xlink:href on mfrac links the whole subtree, not just the fraction stroke
: xlink:href on mfrac links the whole subtree, not just the fraction stroke
Status: RESOLVED WORKSFORME
:
Product: Core
Classification: Components
Component: MathML (show other bugs)
: unspecified
: x86 Linux
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-04-13 07:09 PDT by Christoph Lange
Modified: 2012-04-24 01:14 PDT (History)
1 user (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Test case: mfrac with an XLink and children that link somewhere else (983 bytes, application/xhtml+xml)
2010-04-13 07:11 PDT, Christoph Lange
no flags Details

Description Christoph Lange 2010-04-13 07:09:46 PDT
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.3) Gecko/20100409 Gentoo Firefox/3.6.3
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.3) Gecko/20100409 Gentoo Firefox/3.6.3

I use XLinks in order to link Presentation MathML symbols to their definitions in OpenMath Content Dictionaries.  I will attach a sample document.  Normal operators can easily linked using e.g. <mo xlink:href="http://www.openmath.org/cd/arith1#plus>+</mo>.  But for mfrac this does not work.  When I add an XLink to it, it links the mfrac, but not _just_ the mfrac, but also all of its children.  So there is no possibility of making operators that occur inside the fraction link somewhere else.

The behavior that the parent always wins when there are nested links may sound reasonable, and it may be against best practices to nest links at all, but when I want to link mfrac to http://www.openmath.org/cd/arith1#divide but operators inside the mfrac to some other target, I am forced to nest links, because there is no <mo>-like symbol for mfrac.

So what I would like to suggest is that an xlink:href on mfrac only affects the fraction stroke, not the whole fraction expression including all children.

This might be a general challenge for MathML; therefore I will also discuss this issue on W3C's MathML list.

Reproducible: Always

Steps to Reproduce:
1. Open the attached document.
2. Middle-click (assuming Linux) the "plus" in a+b.

Actual Results:  
Leads to "divide"

Expected Results:  
Should lead to "plus" (as the XLink on the other + operator does)

Here I report this for XLink, but as soon as bug 534968 will be addressed, the same problem may hold for @href.
Comment 1 Christoph Lange 2010-04-13 07:11:04 PDT
Created attachment 438750 [details]
Test case: mfrac with an XLink and children that link somewhere else
Comment 2 Christoph Lange 2010-04-13 07:25:34 PDT
Here is the related discussion on the MathML list: http://lists.w3.org/Archives/Public/www-math/2010Apr/thread.html#msg13
Comment 3 Frédéric Wang (:fredw) 2010-04-18 05:23:56 PDT
Hi Christoph,

I don't think your proposal will work in general (for example the bar of mfrac can have linethickness=0). Also, I think it would be difficult to implement in Mozilla: the bar is not a real C++ object, it only "lives" when we draw it so we can really catch event from it. What you would need is maybe a UI that proposes all the possible links of the MathML elements you click on.
Comment 4 Frédéric Wang (:fredw) 2011-08-07 03:11:54 PDT
Your test case works for me. Probably bug 427990 fixes the issue.
Can you please try with Aurora:

http://www.mozilla.com/en-US/firefox/channel/
Comment 5 Frédéric Wang (:fredw) 2012-04-05 13:24:00 PDT
It seems to me that now the child element always wins.
Christoph, do you still have the issue?
Comment 6 Christoph Lange 2012-04-23 14:44:20 PDT
Thanks, Fréd, with Firefox 10 I am now able to click on the linked fraction stroke.  Not always though.  In my test case in comment 1 above you still have to take care not to accidentally select the "plus" in the numerator.  If you select the link without traversing it (e.g. by hitting TAB several times) you will see that it is much larger than the plus sign; it even extends below the fraction stroke.  But on the other hand a smaller link would make the plus sign hard to focus, so altogether I think the current solution is sufficient.

Note You need to log in before you can comment on or make changes to this bug.