Closed Bug 130889 Opened 22 years ago Closed 20 years ago

caret can get stuck in a cycle if you use an <mtable>

Categories

(Core :: MathML, defect)

Product:
Core
Component:
MathML
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 256835

People

(Reporter: steve.swanson, Assigned: rbs)

Details

Attachments

(2 files)

testcase
656 bytes, application/xhtml+xml
Details
testcase with invisible operators
1.69 KB, application/XHTML+XML
Details 
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: