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)

x86
Windows 2000
defect
Not set
normal

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>&Sum;</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.
Attached file testcase
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
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.
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.
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.
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).
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)
*** 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.

Attachment

General

Creator:
Created:
Updated:
Size: