Closed
Bug 130889
Opened 23 years ago
Closed 20 years ago
caret can get stuck in a cycle if you use an <mtable>
Categories
(Core :: MathML, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 256835
People
(Reporter: steve.swanson, Assigned: rbs)
Details
Attachments
(2 files)
1. Turn on the caret with
user_pref("accessibility.browsewithcaret", true);
2. Open the following XHTML+MathML document
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1 plus MathML 2.0//EN"
"http://www.w3.org/TR/MathML2/dtd/xhtml-math11-f.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<body>
First
<math xmlns="http://www.w3.org/1998/Math/MathML">
<mo>∑</mo>
</math>
Second
<math xmlns="http://www.w3.org/1998/Math/MathML">
<mrow>
<mtable>
<mtr>
<mtd> <mi>x</mi> </mtd>
<mtd> <mi>y</mi> </mtd>
</mtr>
<mtr>
<mtd> <mi>z</mi> </mtd>
<mtd> <mi>w</mi> </mtd>
</mtr>
</mtable>
</mrow>
</math>
Last.
</body>
</html>
3. Put the caret near the start of the line and arrow right. Note how you
successfully move through the entries of the matrix, but when you expect to
move past the end of the matrix, the caret moves to the beginning of the line.
Similar behavior occurs if you start at the end of the line and arrow left.
My initial suspicion is that something has to cater for the fact that the table
is used here as an inline table.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reporter | ||
Comment 3•23 years ago
|
||
1. This cyclic behavior is not restricted to <mtable> as illustrated in the
first example in the testcase.
2. The caret may get stuck in a cycle of length 1 (i.e. it doesn't move) as
illustrated in the second example in the testcase.
Reporter | ||
Comment 4•22 years ago
|
||
This comment applies to my testcase with invisible operators. I still haven't
found a solution to the <mtable> problem.
In nsFrame::GetFrameFromDirection() near line 4217 is says:
newFrame->GetRect(testRect);
if (testRect.IsEmpty()) { // this must be a non-renderable frame creatd at
the end of the line by Bidi reordering
lineJump = PR_TRUE;
aPos->mAmount = eSelectNoAmount;
}
This comment is wrong. Not only do we fall into this code during the
testcase, you also hit it when trying to caret over an empty span:
<span></span>.
I changed the conditional to
if (lineIsReordered && testRect.IsEmpty())
and both the testcase and an empty span work as desired.
However, I have no feel for how bidi works, so don't know if this is the
correct solution.
Reporter | ||
Comment 5•22 years ago
|
||
I agree with Comment #2. The frame traversal code
(nsFrame::GetFrameFromDirection() and probably other places) sees the <mtable>
as a block object, so shouldn't have content on the left or right.
Short of writing a whole bunch of special frame traversal code, I think this
bug will have to wait for Bug 18217 to be fixed.
Comment 6•22 years ago
|
||
I think the change in comment 4 will be OK for Bidi. I'll play with it and come
up with a testcase or two.
The case of invisible operators has now been fixed by bug 202046 in which this
patch was checked in: attachment 125860 [details] [diff] [review] (this patch does exactly what the
analysis in comment 4 revealed).
Reporter | ||
Comment 8•21 years ago
|
||
I believe I now have a fix for the mtable case. This is a little embarassing,
because it's the same fix I proposed for the invisible operator case, only on
a different line. Here is the diff:
@@ -4053,7 +4053,8 @@
if (aPos->mJumpLines != PR_TRUE)
return NS_ERROR_FAILURE;//we are done. cannot jump lines
#ifdef IBMBIDI
- lineJump = PR_TRUE;
+ if (lineIsReordered)
+ lineJump = PR_TRUE;
#endif
if (aPos->mAmount != eSelectWord)
{
This patch makes caret movement in MathML documents much more useful. And,
since the change for invisible operators has already been running for a while
(comment 7), I suspect this one is reasonably safe.
it will be fixed with bug 256835's patch
(the second testcase has a <hr> issue filed as bug 256833)
Comment 10•20 years ago
|
||
*** This bug has been marked as a duplicate of 256835 ***
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•