Closed
Bug 563365
(LookupOperator)
Opened 15 years ago
Closed 15 years ago
nsMathMLOperators::LookupOperators retrieves only the first form found
Categories
(Core :: MathML, defect)
Core
MathML
Tracking
()
RESOLVED
FIXED
mozilla1.9.3a5
People
(Reporter: fredw, Assigned: fredw)
References
Details
Attachments
(1 file, 1 obsolete file)
6.53 KB,
patch
|
karlt
:
review+
|
Details | Diff | Splinter Review |
This issue is extracted from bug 524275.
nsMathMLOperators::LookupOperators is used to here:
http://mxr.mozilla.org/mozilla-central/source/layout/mathml/nsMathMLmoFrame.cpp#199
and the function calls nsMathMLOperators::LookupOperator (without s) with parameter Flag=0:
http://mxr.mozilla.org/mozilla-central/source/layout/mathml/nsMathMLOperators.cpp#510
The function expects that "gOperatorFound contains all its variants", but it is not what nsMathMLOperators::LookupOperator does.
Attachment #443113 -
Flags: review?(karlt)
Comment 1•15 years ago
|
||
IIUC nsMathMLmoFrame::ProcessTextData causes all forms to use the same default for NS_MATHML_OPERATOR_ACCENT and NS_MATHML_OPERATOR_MOVABLELIMITS, and yet it feels to need to search all forms to see if these values are set on any of them.
That seems less than ideal. Is it possible to get the form so as to get the right default values, or only set these parts of mFlags when the form is known?
What's happening for NS_MATHML_OPERATOR_IS_MUTABLE makes a little more sense because that seems to really mean "might-be-stretchy-or-largeop", but even for that I would expect that the value could be obtained using the correct form?
Assignee | ||
Comment 2•15 years ago
|
||
Most of the characteristics of the operator are set according to attributes or according to the operator dictionary. For the former, we need to wait until we process attributes and for the latter we need to determine the form before. The form is itself based on a "form" attribute or on the position in an mrow. But this position is the one of the whole embellished operator while the attribute & dictionary are based on the core embellished operator. So this seems quite complicated and I'm not sure that what we are doing.
I wonder why we need NS_MATHML_OPERATOR_ACCENT and NS_MATHML_OPERATOR_MOVABLELIMITS. It seems that we should wait to have determined the form before setting/using any accent or movablelimits value.
For NS_MATHML_OPERATOR_IS_MUTABLE, I think it's correct to look to all the possibilities.
Comment 3•15 years ago
|
||
I get the impression that the only reason for using
NS_MATHML_OPERATOR_IS_MUTABLE during frame initialization is for
the -moz-math-stretchy pseudo-element.
http://hg.mozilla.org/mozilla-central/annotate/d6d331e05fca/layout/mathml/mathml.css#l372
That is no longer useful in author stylesheets because -moz pseudo-elements
are no longer processed in author stylesheets. We probably could re-enable
that, but I don't think there's any reason to do so.
That means that the only function of the -moz-math-stretchy pseudo-element is
to ignore document font-style and font-family for nsMathMLChars. I'm guessing
that setting the font-style to normal could be done in nsMathMLChar, and I'm
not sure we want to completely ignore document font-family.
If we don't need to call LookupOperators (with the s) in
nsMathMLmoFrame::ProcessTextData, then we don't need the function at all.
Comment 4•15 years ago
|
||
Comment on attachment 443113 [details] [diff] [review]
Fix nsMathMLOperators::LookupOperator
However, if you'd prefer to just fixup LookupOperators for now, then that is
an option.
I'm not fond of using global variables in the way that gOperatorFound is used
because it leads to bugs such as this, so I'd prefer that this was fixed in a
way that doesn't use gOperatorFound.
How about adding an internal function
static OperatorData*
GetOperatorData(const nsString& aOperator, nsOperatorFlags aForm)
that just looks up the single operator/form in the table (without the fallback
that LookupOperator does), returning NULL if not found?
Then LookupOperator and LookupOperators can just use GetOperatorData directly,
and gOperatorFound can be removed.
Attachment #443113 -
Flags: review?(karlt)
Assignee | ||
Comment 5•15 years ago
|
||
> However, if you'd prefer to just fixup LookupOperators for now, then that is
> an option.
Yes, I prefer not to change too many things in the stretching mechanism for now. I just want to solve the bug with operators that have stretchy and non-stretchy forms. To do this, we must determine NS_MATHML_OPERATOR_MUTABLE from "allFlags" not only the first form found.
For NS_MATHML_OPERATOR_ACCENT and NS_MATHML_OPERATOR_MOVABLELIMITS, I still don't know why they are set during frame initialization. And so I don't know if we should set them using "allFlags" or the first form found. Apparently, the intention was to use "allFlags", so maybe we can do this change?
> I'm not fond of using global variables in the way that gOperatorFound is used
> because it leads to bugs such as this, so I'd prefer that this was fixed in a
> way that doesn't use gOperatorFound.
Yes, I think you're right, gOperatorFound should not be used. I'll try to do that.
Comment 6•15 years ago
|
||
(In reply to comment #5)
> For NS_MATHML_OPERATOR_ACCENT and NS_MATHML_OPERATOR_MOVABLELIMITS, I still
> don't know why they are set during frame initialization. And so I don't know if
> we should set them using "allFlags" or the first form found. Apparently, the
> intention was to use "allFlags", so maybe we can do this change?
Yes, I think that's fine. I was really commenting because it looked like we didn't need LookupOperators.
IIUC NS_MATHML_OPERATOR_ACCENT is only going to have an effect when the operator exists on its own anyway. (That is really infix but currently our code will sometimes choose postfix.)
I don't really know about NS_MATHML_OPERATOR_MOVABLELIMITS but using the first form found is not right. And, as you say, the intention was that all forms would be checked.
Assignee | ||
Comment 7•15 years ago
|
||
nsMathMLOperators::LookupOperator (without s) was used in three places:
* In nsMathMLmfencedFrame.cpp, function GetCharSpacing, which is called in
* nsMathMLmfencedFrame::ReflowChar, called in nsMathMLmfencedFrame::Reflow with INFIX, POSTIX and PREFIX forms.
* GetMaxCharWidth, called in nsMathMLmfencedFrame::GetIntrinsicWidth with INFIX, POSTIX and PREFIX forms.
* In nsMathMLmoFrame.cpp, function nsMathMLmoFrame::ProcessOperatorData, with INFIX, POSTIX or PREFIX forms.
* In nsMathMLOperators::LookupOperators, but the patch now directly uses GetOperatorData
so I've removed the possibility to pass aForm = 0 to retrieve all the forms (anyway it did not work).
Attachment #443113 -
Attachment is obsolete: true
Attachment #445171 -
Flags: review?(karlt)
Comment 8•15 years ago
|
||
Comment on attachment 445171 [details] [diff] [review]
Patch v.2
Nice, thank you.
Attachment #445171 -
Flags: review?(karlt) → review+
Assignee | ||
Updated•15 years ago
|
Keywords: checkin-needed
Comment 9•15 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a5
You need to log in
before you can comment on or make changes to this bug.
Description
•