632215 - Caret stays behind when typing in SMF 2.0 editor

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect)

Description

[Oskar Ivanić (:icecold)]

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:
http://tinypic.com/player.php?v=ibc3na&s=7
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

[Oskar Ivanić (:icecold)]

GOOD -  Build identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre) Gecko/20101105 Firefox/4.0b8pre
http://hg.mozilla.org/mozilla-central/rev/5947e95a21d1

BAD - Build identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre) Gecko/20101106 Firefox/4.0b8pre
http://hg.mozilla.org/mozilla-central/rev/2b612890113b

Comment 2

[Dão Gottwald [:dao]]

bug 372345?

Comment 3

[Oskar Ivanić (:icecold)]

(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

Comment 4

[(no longer active)]

What is the URL of the page on which you're seeing this?  I could not reproduce this on <http://www.simplemachines.org/community/index.php?action=post;board=2.0>...

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

Comment 5

[Oskar Ivanić (:icecold)]

http://forum.baguje.com/
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.

Comment 6

[(no longer active)]

I can reproduce on Linux.  Blocking on this.

Comment 7

[(no longer active)]

This is not a regression from bug 372345.  I reverted those changes locally, and this bug still happens.

Comment 8

[(no longer active)]

(In reply to comment #1)
> GOOD -  Build identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre)
> Gecko/20101105 Firefox/4.0b8pre
> http://hg.mozilla.org/mozilla-central/rev/5947e95a21d1
> 
> BAD - Build identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre)
> Gecko/20101106 Firefox/4.0b8pre
> http://hg.mozilla.org/mozilla-central/rev/2b612890113b

I've verified this regression range locally, and I'm now bisecting it...

Comment 9

[(no longer active)]

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 <[e-mail]>
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+

Interesting!

Comment 10

[(no longer active)]

Attachment: Test case 1

Typing in the iframe results in this buggy caret behavior.

Comment 11

[(no longer active)]

Attachment: 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.

Comment 12

[(no longer active)]

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 <http://mxr.mozilla.org/mozilla-central/source/layout/base/nsCaret.cpp#690> kick in and prevents the caret from being updated.

Comment 13

[(no longer active)]

Attachment: Patch (v1)

Comment 14

[(no longer active)]

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.

Comment 15

[(no longer active)]

Attachment: Tests

Comment 16

[(no longer active)]

Attachment: Part 2: tests

For real this time.

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 511478 [details] [diff] [review]
Part 2: tests

Heroic!

Comment 18

[(no longer active)]

http://hg.mozilla.org/mozilla-central/rev/3eaad34067e4
http://hg.mozilla.org/mozilla-central/rev/7573d5177830

Comment 19

[Carsten Pfeiffer]

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.