selected math objects don't draw their backgrounds as selected

NEW
Unassigned

Status

()

Core
MathML
P5
normal
16 years ago
3 years ago

People

(Reporter: steve.swanson, Unassigned)

Tracking

(Blocks: 1 bug, {helpwanted})

Trunk
x86
Windows XP
helpwanted
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [lang=c++])

Attachments

(2 attachments)

(Reporter)

Description

16 years ago
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

16 years ago
Created attachment 103611 [details]
testcase with fraction, square root and matrix

This is really not a comprehensive testcase.  Just something simple to show the
bug.

Comment 2

16 years ago
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

16 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.

Comment 4

16 years ago
> 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

16 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.

Comment 6

16 years ago
> 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

16 years ago
Created attachment 106311 [details] [diff] [review]
patch for bug

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.
QA Contact: ian → mathml
Assignee: rbs → nobody
Blocks: 539506
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.
(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.
Priority: -- → P5
Keywords: helpwanted
Whiteboard: [mentor=fredw][lang=c++]

Updated

4 years ago
Whiteboard: [mentor=fredw][lang=c++] → [mentor=fredw][lang=c++][good next bug]
(Assignee)

Updated

4 years ago
Mentor: fred.wang
Whiteboard: [mentor=fredw][lang=c++][good next bug] → [lang=c++][good next bug]

Comment 10

4 years ago
Hi Fred, i'd like to attempt this bug.
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.
It should appear in any system. Do Ctr+A on attachment 103611 [details] and you'll see that only the text nodes have background.
Mentor: fred.wang
Whiteboard: [lang=c++][good next bug] → [lang=c++]
You need to log in before you can comment on or make changes to this bug.