Closed
Bug 748779
Opened 13 years ago
Closed 12 years ago
maction@toggle should not modify the DOM
Categories
(Core :: MathML, defect)
Core
MathML
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: fredw, Assigned: PraZuBeR)
References
Details
Attachments
(1 file)
(deleted),
text/html
|
Details |
In order to change the selected frame, nsMathMLmactionFrame::MouseClick sets a "selection" attribute to the maction element.
This is bad: when the document is serialized (when you save the page or show the source for example), you get this unwanted selected attribute. Also, this may prevent mstyle@selected to have any effect on a descendant <maction> when it is set via javascript after the user clicked on the <maction> (see the testcase).
Ideally, we should only memorize the selected frame in a nsMathMLmactionFrame private members.
Comment 1•13 years ago
|
||
The spec appears to explicitly require that the attribute is changed:
"Each click increments the selection value"
and that this has an effect on the serialization:
"If a MathML application responds to a user command to copy a MathML sub-expression to the environment's "clipboard" (see Section 6.3 Transferring MathML), any maction elements present in what is copied should be given selection values that correspond to their selection state in the MathML rendering at the time of the copy command."
http://www.w3.org/TR/MathML3/chapter3.html#id.3.7.1.1
(In reply to Frédéric Wang from comment #0)
> Also,
> this may prevent mstyle@selected to have any effect on a descendant
> <maction> when it is set via javascript after the user clicked on the
> <maction> (see the testcase).
I see the issue here, but I think the behaviour is clear from the spec and authors can know what to expect.
Reporter | ||
Comment 2•13 years ago
|
||
I don't know if "selection value" and "selection state in the MathML rendering" refer to the "selection attribute value", although it would be much easier for us to implement the "Transferring MathML" requirement.
Maybe we should really just ignore the selection attribute on mstyle, which is not really useful in that case and is conflicting with toggle/javascript (that would also be an easy fix for bug 734729, even if my comment there still holds).
We should probably ask the Math WG about that.
Comment 3•13 years ago
|
||
(In reply to Frédéric Wang from comment #2)
> Maybe we should really just ignore the selection attribute on mstyle, which
> is not really useful in that case and is conflicting with toggle/javascript
I feel that many of the attributes on mstyle are not so useful.
Perhaps though one may have many non-toggle maction elements within a single mstyle and javascript may be used to change the selection attribute on mstyle to change the selected child for all the maction elements. It's an edge case that I doubt is worth much effort.
Reporter | ||
Comment 4•12 years ago
|
||
I don't remember the WG's response but I think this is WONTFIX.
Isn't it a security issue that we modify the DOM from layout/?
Comment 5•12 years ago
|
||
Modifying the DOM during layout and frame construction can cause security issues, but it should be fine to set an attribute in response to a mouse event.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•