Closed Bug 539323 Opened 15 years ago Closed 14 years ago

Can't type in contentEditable

Categories

(Core :: DOM: Editor, defect)

Product:
Core
Component:
DOM: Editor
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
blocking2.0 --- -
status2.0 --- wanted

People

(Reporter: bmccann, Assigned: roc)

Details

Attachments

(3 files)

Test case
267 bytes, text/html
Details
testcase #2
162 bytes, text/html
Details
fix for part 1
3.35 KB, patch
MatsPalmgren_bugz
: review+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7

Can't type in an empty contentEditable.  See the attached file for a super tiny test case.

Reproducible: Always

Steps to Reproduce:
1. Open attached file
Actual Results:  
Can't type in contentEditable

Expected Results:  
Should be able to type in contentEditable
Attached file Test case — 

    
    

    
  
Works fine for me.  Tab to the box, and type.  Now _focusing_ the box with a mouseclick doesn't work, but that's because you're clicking on transparent parts of it (which don't get the click event), right?

    
    

    
  
Tabbing to the box half works.  You can tab into it, but the cursor is invisible.
Correct, focusing the box with a mouse click does not work.  I expect that it should (not sure what you mean by it being transparent).

    
    

    
  
Hmm.  I guess even transparent frames should get click events...  Enn, any idea what's up with focus here?
Component: General → Editor
Product: Firefox → Core
QA Contact: general → editor
Status: UNCONFIRMED → NEW
Ever confirmed: true
blocking2.0: --- → ?

    
    

    
  
Focus looks to be working fine. The caret just isn't drawing when it should.

1. Click the rectangle.
2. Start typing. The entered characters appear. The caret only appears when there are characters in the box.

Possibly the caret is being rendered with no height or because there is no content.

    
    

    
  
If you click once in the box, you can type, but the cursor will not appear.  If you click three or more times in the box then you cannot type in the box and the cursor is not visible.
Assignee: nobody → roc
blocking2.0: ? → -

          status2.0:
          --- → wanted

    
    

    
  

      
      
      
      

        Attached file
          
        testcase #2
        — 
      

    


  
The problem is that on the initial click, the caret is shown but it's positioned at the left edge of the border-box. So if the element has a black border, you can't see the caret. Having it next to the dotted focus rect also makes it hard to see. We should at least position it relative to the padding-box, since that's where inserted content would appear.

        Attachment #421333 -
        Attachment is obsolete: true

        Attachment #421333 -
        Attachment is obsolete: false

    
    

    
  

      
      
      
      

        Attached patch
          
          
        fix for part 1
        — 
          — Splinter Review
      

    


  
This patch makes the caret position use the container frame's content-box instead of the border-box. This makes sense to me since it more accurately represents where content would actually be rendered if it was to be inserted at the caret position.

Mats, can we test this with reftests now?

There's a remaining problem in this bug, which is that clicking in the element after it already has focus makes the caret disappear and you can't type into the element anymore.

        Attachment #425777 -
        Flags: review?(matspal)

    
    

    
  
When the div has focus, and I click again, we go into a state where the selection has no ranges. That's why there's no caret displayed and typing does nothing. Maybe that's more of a focus-related problem?
Whiteboard: [needs review]

    
    

    
  
I don't see any focus change on second click. The focus manager returns early and does nothing as the <div> is already focused.

After the first click, the selection contains the range:
 <div>, 0 to <div>, 0

After the second click, the selection contains the range:
 <body>, 1 to <body>, 2

Seems like the caret position on click handling isn't dealing with an empty contenteditable perhaps?

    
    

    
  
Comment on attachment 425777 [details] [diff] [review]
fix for part 1

Makes sense to me too, r=mats

Reftest now draws the caret solid (non-blinking) by default.
If you need privileges you can do it in mochitest too, see
layout/base/tests/test_reftests_with_caret.html for an example.

I assume you'll make a reftest of Testcase #2.
Would be nice to also have tests for the edge cases
"width:0; padding:0" and "width:0; padding:1em".

Spawn off the remaining problem as a separate bug?

        Attachment #425777 -
        Flags: review?(matspal) → review+
OS: Windows XP → All
Hardware: x86 → All
Whiteboard: [needs review]
Whiteboard: [needs landing]

    
    

    
  
http://hg.mozilla.org/mozilla-central/rev/0a02b6c9d9b4

Remaining problem filed as bug 550434.
Status: NEW → RESOLVED
Closed: 14 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [needs landing]

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: