Closed Bug 579760 Opened 14 years ago Closed 3 years ago

Caret ("cursor") disappears before span with set background-color in iframe in designmode (rich text editor)

Categories

(Core :: DOM: Editor, defect)

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

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: cacyclewp, Unassigned)

References

(
URL
)

Details

(Keywords: good-first-bug)

Attachments

(2 files, 2 obsolete files)

Testcase
1.18 KB, text/html
Details
missingTextCursorOnGoogleSpreadsheet.png
15.02 KB, image/png
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6 ( .NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6 ( .NET CLR 3.5.30729)

The caret ("cursor") disappears when positioned from the left just before a span with set background-color style in iframes in designmode. This is a major problem in all existing rich text editors.

It only happens when moving the caret to the right, not when moving the caret to the left. It also happens only on the left side of the span. It does not happen when setting other styles such as color or border. It happens for all tested inline elements (<span>, <font>, <i>). It does not happen if the start of the span is at the beginning of a new line, e.g. after a <br> or for block level elements.


Reproducible: Always
Attached file Testcase (obsolete) — 

    
    

    
  

      
      
      
      

        Attached file
          
        Testcase (obsolete)
        — 
      

    


  

        Attachment #458195 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached file
          
        Testcase
        — 
      

    


  

        Attachment #458196 -
        Attachment is obsolete: true

    
    

    
  
A similar but maybe unrelated bug is described in 579763.

    
    

    
  
A similar but maybe unrelated bug is described in bug 579763.

    
    

    
  
I can confirm this for FF 3.6.12 as well as today's nightly build of FF 4.0b8pre using Windows XP SP3.

    
  
Version: unspecified → Trunk
Product: Firefox → Core
QA Contact: general → general
Component: General → Editor
QA Contact: general → editor

    
    

    
  
Changing the status to "New," as this is confirmed in the latest nightly build of Firefox on my end.
Status: UNCONFIRMED → NEW
Ever confirmed: true

    
  
Assignee: nobody → ehsan
Whiteboard: [post-2.0]

    
  
Assignee: ehsan → nobody
See Also:  → 579763

    
  
Whiteboard: [post-2.0]

    
    

    
  


  
Here's a real world example:

1. Go to https://docs.google.com/spreadsheets/d/1-CERGJ75bZKrk73cWCqXtU2yBQYbNkSraymMW96efeo/edit?pli=1#gid=1950799756
2. Switch to the 'Abs. Numbers Monthly Summary' sheet
3. Select table cell B19
4. Click between the equal sign and the apostrophe inside the formula input field

Sebastian

    
    

    
  
Here's a simpler test case (using contenteditable):

data:text/html,<!DOCTYPE html><div contenteditable="true">a<span style="background:lightblue;">b</span></div>

Set the text cursor before the a and then move it one to the right.

=> The text cursor disappears.

Sebastian
OS: Windows XP → All
Hardware: x86 → All
Whiteboard: [good first bug]

    
    

    
  
Build identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Firefox/38.0

Can confirm it's there in FF 38.0.1

    
    

    
  
Can I work on this? It's my first bug. I heard editor code can be a bit hairy. But I feel I can do it.

    
    

    
  
I think I didn't reply to this earlier. If so, sorry for that!
I assigned the bug to you now, Sreejith. Thank you for taking it over! Please let me know if I can be of any help!

Sebastian
Assignee: nobody → sreejith.r44
URL: data:text/html,<!DOCTYPE html><div co...

    
    

    
  
@Sebastian I'll start on this. Will let you know about updates.

    
    

    
  
This bug is still present in 52.0.1 (Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0) and is still a problem. Sreejith: are you still on it? If not: anybody willing to work on this?

    
    

    
  
If he's not, I'd like to take over.

    
    

    
  
As Sreejith never provided a patch and wasn't active anymore on Bugzilla after his comment above, I think it's fine if you take over this bug, Michael. Therefore I've assigned it to you.

Sebastian
Assignee: sreejith.r44 → michaeljohnyoder
Status: NEW → ASSIGNED

    
    

    
  
Another example is: <div contenteditable="true">&zwnj;<span style="background-color:antiquewhite;">qwer</span></div>
If you place the selection on the zwnj text node at offset 0 or 1, the caret will be invisible. Moving right/left works as expected.
Keywords: good-first-bug
Whiteboard: [good first bug]

    
    

    
  
This good-first-bug hasn't had any activity for 2 months, it is automatically unassigned.

For more information, please visit auto_nag documentation.


Assignee: michaeljohnyoder → nobody
Status: ASSIGNED → NEW

    
    

    
  
Hello @sebo, this Vaidehi, an outreachy applicant. Would like to work on this bug if it's still open.

It would be great if you can provide assistance in reproducing it and directing to the files which need to be examined.



    
    

    
  
Hi Vaidehi! Thank you for your interest!


Actually, this bug isn't reproducible for me anymore. The original reporter and I had provided several test cases in the previous comments and in comment 8 I also provided clear steps to reproduce the problem.

Though in all of them the caret is visible now in all situations (except when the caret has the same color as the background or border, but that's another issue). I've tested this on Windows 10 with Firefox 87.0 and WebRender enabled. So it obviously got fixed in the meantime.


Therefore, I finally close this bug now. If anyone can still reproduce it, feel free to reopen it and provide information about the system you tested it on.


Sebastian


Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: