Open
Bug 175850
Opened 22 years ago
Updated 2 years ago
selected math objects don't draw their backgrounds as selected
Categories
(Core :: MathML, defect, P5)
Tracking
()
NEW
People
(Reporter: steve.swanson, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: helpwanted, Whiteboard: [lang=c++])
Attachments
(2 files)
1.53 KB,
application/xhtml+xml
|
Details | |
15.92 KB,
patch
|
Details | Diff | Splinter Review |
Load the testcase. Use Edit Select All to select the whole document. The
individual letters and symbols have their backgrounds drawn blue (on WinXP),
but the large objects such as the fraction and the matrix leave their
background white.
I built a patch to fix this by changing nsMathMLContainerFrame::Paint().
Something else may be needed to fix the matrix (<mtable>) case.
I understand that A) this may not be the right place to change the behavior,
and b) there may be some ambiguity about what the correct behavior is. But if
the nsMathMLmfracFrame knows that it's been selected, why shouldn't it display
itself that way?
Reporter | ||
Comment 1•22 years ago
|
||
This is really not a comprehensive testcase. Just something simple to show the
bug.
This bug seems to come from the lack of "structured selection" in MathML. What
we have now is what HTML is doing. For example, when an entire HTML table is
selected, only the _text_ in the table appears as selected. Whereas this bug
wants the whole background of a MathML table/matrix to appear as selected (this
can somewhat be seen in the Composer which has a special way for selecting a
cell/row/column/table. Try Insert->Table and Table->Select->All Cells -- the
selection border could have been a selection background).
It seems to me that structured selection throughout MathML can be achieved in a
general way as follows:
. if all children of a container are selected, mark the container itself as selected
. if a container is selected, mark all its children selected (so that other
operations such as copy-paste stay in sync).
Hope I am not missing something here?
Reporter | ||
Comment 3•22 years ago
|
||
I disagree. When you use Select All, all the MathML frames ARE marked as
selected. The bug is that they are not drawing themselves correctly in this
case.
Structured selection is a long term goal, but I thought pulling off this small
piece would help make some small progress.
> The bug is that they are not drawing themselves correctly in this
> case.
Note that for HTML elements, even if selected, only their textframe children get
rendered as selected. So painting the whole background as selected is specific
to MathML, right?
If yes, and it is implemented that way, then it would be more consistent to also
implement the two aspects I mentioned above. Otherwise there could be a
situation where the numerator and denominator are selected (e.g., with the
mouse), and yet the whole background of the fraction isn't painted as selected.
What about using this bug to address the issue as a whole. If it turns to be
hard, ambitions can be downgraded.
Reporter | ||
Comment 5•22 years ago
|
||
I don't know if the HTML behavior is correct or not. I'm willing (eager!) to
restrict the discussion to MathML. Generally, only leaf text in HTML is drawn
as selected, but consider an <hr>. And, of course, tables.
I'm happy to expand this bug to include selection behavior. The drawing is a
minor issue, but it has to repaired for the selection behavior to work
correctly. Sometimes, though, separating into finer-grained bugs is a better
idea. Witness my fix for the simple case of bug 130889, which seems to have
been ignored because the larger bug is relatively intractible.
Roger, I will work on this bug soon, trying hard to stay within the confines
of the MathML code. Feel free to wait for a patch from me (or a plea for
help) before looking further.
> Sometimes, though, separating into finer-grained bugs is a better
> idea.
True. But I have found that doing a bigger _analysis_ often helps to avoid
troubles down the track. Then, fanning out into little bugs might follow. Time
and again we have had to back-out layout patches that are designed with too
little context in mind.
> Witness my fix for the simple case of bug 130889, which seems to have
> been ignored because the larger bug is relatively intractible.
From my reading of bug 130889 comment 4, you are not personnally convinced
yourself whether the patch is correct or not :-) Suggesting to get in touch with
bidi people or dig further to know more and convince yourself.
Reporter | ||
Comment 7•22 years ago
|
||
The patch does not address the structured selection issues mentioned in Comment
2 and below. I'm having trouble getting much traction there, and don't want to
lose what I've done so far.
The patch also includes the fixes for bug 175845 since there is significant
overlap.
With this patch, a Select All in a MathML document looks much better than
before.
Updated•15 years ago
|
QA Contact: ian → mathml
Updated•15 years ago
|
Assignee: rbs → nobody
Updated•12 years ago
|
Blocks: mathml-clipboard
Comment 8•12 years ago
|
||
I'm not sure we want to draw a background rect for the whole bounding box of a selected MathML element. Perhaps only some background around a graphic component is necessary (bug 175845 comment 28).
However, some ideas in comment 2 seem important. I don't know exactly how it is currently implemented but I noticed that if you select one child of, say a <sqrt>, the nsMathMLmsqrt::IsSelected() returns true and the so the square root symbol and bar would be drawn as selected (if bug 175845 is fixed) while some other children may not be drawn as selected.
Comment 9•12 years ago
|
||
(In reply to Frédéric Wang (:fredw) from comment #8)
> I'm not sure we want to draw a background rect for the whole bounding box of
> a selected MathML element. Perhaps only some background around a graphic
> component is necessary (bug 175845 comment 28).
I tried to implement it that way and I also compared with what other programs like Amaya or MathType do. Now I think Steve Swanson's approach (drawing a background rectangle for the whole element bounding box) would be the best and consistent with other programs. BTW, his patch also seems to address bug 759462.
As discussed in this bug, the way selection is determined should indeed be improved, but we might take the patch without this additional work if that does not make the situation worse.
Updated•12 years ago
|
Priority: -- → P5
Updated•12 years ago
|
Keywords: helpwanted
Whiteboard: [mentor=fredw][lang=c++]
Updated•11 years ago
|
Whiteboard: [mentor=fredw][lang=c++] → [mentor=fredw][lang=c++][good next bug]
Assignee | ||
Updated•11 years ago
|
Mentor: fred.wang
Whiteboard: [mentor=fredw][lang=c++][good next bug] → [lang=c++][good next bug]
Comment 10•10 years ago
|
||
Hi Fred, i'd like to attempt this bug.
Comment 11•9 years ago
|
||
Hello Frédéric Wang,
Is this bus still open? Quick question does this bug only appear on a x86 Windows XP system because I don't see the bug on x86-64 win8.1 every thing seems to work fine.
Comment 12•9 years ago
|
||
It should appear in any system. Do Ctr+A on attachment 103611 [details] and you'll see that only the text nodes have background.
Updated•9 years ago
|
Mentor: fred.wang
Whiteboard: [lang=c++][good next bug] → [lang=c++]
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•