Caret stays behind when typing in SMF 2.0 editor

RESOLVED FIXED in mozilla2.0b12



8 years ago
8 years ago


(Reporter: icecold, Assigned: Ehsan)



Windows 7
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(blocking2.0 final+)


(Whiteboard: [softblocker])


(4 attachments, 1 obsolete attachment)



8 years ago
User-Agent:       Mozilla/5.0 (Windows NT 6.1; rv:2.0b12pre) Gecko/20110207 Firefox/4.0b12pre
Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b12pre) Gecko/20110207 Firefox/4.0b12pre

When I start typing in Simple Machines Forum editor (forum based on SMF ofc), vertical line stays behind letters that I'm typing.

Here is a video record of problem:
Compared in Firefox 4 pre beta 12 and Google Chrome 9.
(it works in all other browsers too)

Reproducible: Always

Actual Results:  
Vertical line stayed behind letters while I was typing 

Expected Results:  
Vertical line should follow letters as I type

Comment 1

8 years ago
GOOD -  Build identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre) Gecko/20101105 Firefox/4.0b8pre

BAD - Build identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre) Gecko/20101106 Firefox/4.0b8pre
Version: unspecified → Trunk
bug 372345?
Blocks: 372345
Component: General → Editor
Keywords: regression
Product: Firefox → Core
QA Contact: general → editor

Comment 3

8 years ago
(In reply to comment #2)
> bug 372345?

Just tried simple test case in that bug and it's fine.
This doesn't seem like bug 372345
What is the URL of the page on which you're seeing this?  I could not reproduce this on <;board=2.0>...

roc: this sounds like something on which we should block, if I can get to reproduce it.
blocking2.0: --- → ?

Comment 5

8 years ago
You're able to login with Facebook account so you don't have to register. 
I'm also not able to reproduce it on SMF page just like you.
I can reproduce on Linux.  Blocking on this.
Assignee: nobody → ehsan
blocking2.0: ? → final+
Ever confirmed: true
Whiteboard: [softblocker]
Summary: Vertical line stays behind when typing in SMF 2.0 editor → Caret stays behind when typing in SMF 2.0 editor
This is not a regression from bug 372345.  I reverted those changes locally, and this bug still happens.
No longer blocks: 372345
(In reply to comment #1)
> GOOD -  Build identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre)
> Gecko/20101105 Firefox/4.0b8pre
> BAD - Build identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre)
> Gecko/20101106 Firefox/4.0b8pre

I've verified this regression range locally, and I'm now bisecting it...
Hmm, here is the result of bisecting:

ehsan@ehsan-Macmini:~/moz/src$ hg bis -b
The first bad revision is:
changeset:   56924:25e44442a6e8
user:        Ehsan Akhgari <>
date:        Fri Oct 29 12:30:15 2010 -0400
summary:     Bug 372345 - [Midas] text cursor overrides CSS mouse cursor styles for some elements; r=bzbarsky a=blocking-final+

Blocks: 372345
Posted file Test case 1
Typing in the iframe results in this buggy caret behavior.
Posted file Test case 2
This test case also demonstrates the problem.  The difference here is that the iframe document's body has a contenteditable attribute initially.
The bug is caused because of the fact that the body element in the iframe document ends up having the -moz-user-modify: read-only style, which makes this check <> kick in and prevents the caret from being updated.
Whiteboard: [softblocker] → [softblocker][has wip][needs try results]
Comment on attachment 511284 [details] [diff] [review]
Patch (v1)

This is looking good so far.  The philosophy behind this patch is that currently calling SetCaretVisible(PR_TRUE) will turn the ignore user modify flag on not immediately, but after the caret timer fires.  This can cause the caret to "jump" in cases like this.  I guess we've had this bug since forever, it has just been exposed using this weird interaction of things on this page.  With my patch, the ignore user modify flag is turned on for the synchronous painting of caret in addition to future caret timer events.

I thought a lot about how to write a test for it, but my experiments have not been successful yet.  But I haven't gave up on a test for this yet.  If I write one, I'll attach another patch.
Attachment #511284 - Attachment description: WIP → Patch (v1)
Attachment #511284 - Flags: review?(roc)
Whiteboard: [softblocker][has wip][needs try results] → [softblocker][has patch][needs review roc]
Whiteboard: [softblocker][has patch][needs review roc] → [softblocker][needs landing]
Posted patch Tests (obsolete) — Splinter Review
Attachment #511477 - Flags: review?(roc)
Posted patch Part 2: testsSplinter Review
For real this time.
Attachment #511477 - Attachment is obsolete: true
Attachment #511478 - Flags: review?(roc)
Attachment #511477 - Flags: review?(roc)
Comment on attachment 511478 [details] [diff] [review]
Part 2: tests

Attachment #511478 - Flags: review?(roc) → review+
Last Resolved: 8 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [softblocker][needs landing] → [softblocker]
Target Milestone: --- → mozilla2.0b12

Comment 19

8 years ago
Any chance of getting this backported to a xulrunner 1.9.2 build (i.e. one where JavaXPCOM is still available)?

This bug makes xulrunner 1.9.2 pretty much unusable for us.
You need to log in before you can comment on or make changes to this bug.