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
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
Version: unspecified → Trunk
(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 <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.
blocking2.0: --- → ?
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.
I can reproduce on Linux. Blocking on this.
Assignee: nobody → ehsan
Status: UNCONFIRMED → ASSIGNED
blocking2.0: ? → final+
Ever confirmed: true
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 > 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...
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 <firstname.lastname@example.org> 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!
Typing in the iframe results in this buggy caret behavior.
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 <http://mxr.mozilla.org/mozilla-central/source/layout/base/nsCaret.cpp#690> 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.
Whiteboard: [softblocker][has wip][needs try results] → [softblocker][has patch][needs review roc]
Attachment #511284 - Flags: review?(roc) → review+
Whiteboard: [softblocker][has patch][needs review roc] → [softblocker][needs landing]
For real this time.
Comment on attachment 511478 [details] [diff] [review] Part 2: tests Heroic!
Attachment #511478 - Flags: review?(roc) → review+
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Whiteboard: [softblocker][needs landing] → [softblocker]
Target Milestone: --- → mozilla2.0b12
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.