Caret ("cursor") disappears before span with set background-color in iframe in designmode (rich text editor)
Categories
(Core :: DOM: Editor, defect)
Tracking
()
People
(Reporter: cacyclewp, Unassigned)
References
()
Details
(Keywords: good-first-bug)
Attachments
(2 files, 2 obsolete files)
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
A similar but maybe unrelated bug is described in bug 579763.
Comment 6•14 years ago
|
||
I can confirm this for FF 3.6.12 as well as today's nightly build of FF 4.0b8pre using Windows XP SP3.
Updated•13 years ago
|
Updated•13 years ago
|
Updated•13 years ago
|
Comment 7•13 years ago
|
||
Changing the status to "New," as this is confirmed in the latest nightly build of Firefox on my end.
Updated•13 years ago
|
Updated•10 years ago
|
Comment 8•10 years ago
|
||
str |
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
Comment 9•9 years ago
|
||
str |
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
Comment 10•9 years ago
|
||
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
Comment 11•9 years ago
|
||
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.
Comment 12•9 years ago
|
||
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
Comment 13•9 years ago
|
||
@Sebastian I'll start on this. Will let you know about updates.
Reporter | ||
Comment 14•7 years ago
|
||
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?
Comment 15•7 years ago
|
||
If he's not, I'd like to take over.
Comment 16•7 years ago
|
||
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
Comment 17•7 years ago
|
||
Another example is: <div contenteditable="true">‌<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.
Updated•6 years ago
|
Comment 18•3 years ago
|
||
This good-first-bug hasn't had any activity for 2 months, it is automatically unassigned.
For more information, please visit auto_nag documentation.
Comment 19•3 years ago
|
||
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.
Comment 20•3 years ago
|
||
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
Description
•