To repro: click in textarea at bottom of http://george-w-dance.homepage.com/ .

Updating QA Contact

I'm not clear on the bug symptoms. I see the cursor flicker in the text area. Is that the problem? -p

Yep.

This happens with the throbber and the location bar too.

... and with the broken "buddy list" sidebar tab and the location bar.

This could be caused by bug 60880.

All pnunn bugs reassigned to Pav, who is taking over the imglib.

Reporter, are you still experiencing this bug? The page that was used is no longer present and I can't see anything with the testcase either, thanks

Confirming on build 2001-06-26-11, Win98 When both an animated GIF and a selected text field are visible, the animated GIF resets the blinking cursor for each new GIF frame. It's like the cursor is on turbo-blink. Steps to reproduce: 1. Create a text-field on the same page as an animated GIF. 2. Click in the text field I would create a testcase for you, but I can't (I'm at work hehe). Filing this is just about all I can do... Adding myself to CC.

Forgot to add... When the GIF is no longer visible (i.e. scrolled out of view), it no longer produces this effect.

okay... since the testcase and url no longer works could someone be nice enough to create another testcase?

*** Bug 131577 has been marked as a duplicate of this bug. ***

testcase from bug 131577: attachment 74622 [details]. os->all

*** Bug 141636 has been marked as a duplicate of this bug. ***

*** Bug 148087 has been marked as a duplicate of this bug. ***

This also happens with the search box on http://netscape.com/. In that case, this bug is not triggered by an animation, but by a javascript news ticker. Imagelib isn't the right place for this bug. I'll try HTML Form Controls.

I have a fix for this in my local tree, I'm working out some caret cruft issues. This problem is not image related, but rather painting related. We turn off the caret before painting anything to the screen and turn it on afterwards.

Work in progress patch ... This patch fixes the reported problem for animations that don't intersect with text widgets. As mentioned above I'm still working out caret cruft issues with this patch ... for example hitting return at the bottom of the document in a scrollable composer window.

nsbeta1+.

I was about to check if this cures the almost-invisible-caret-when-typing in autocomplete fields, but the patch has rotten a bit too much for me.

Reproduced in 12/16 Trunk build on Win XP

*** Bug 186542 has been marked as a duplicate of this bug. ***

This patch includes some changes to W.I.P patch above in order to catch up with trunk. This works fine for me. New test case is here. http://bugzilla.mozilla.gr.jp/attachment.cgi?id=1475&action=view In this test case, caret flickers wrong frequency as non-flickering.

*** Bug 196429 has been marked as a duplicate of this bug. ***

Comment on attachment 113396 [details] [diff] [review] W.I.P. patch 1 with some changes Though this patch works, it is not ready for review. Like I said earlier, there were some issues that still needed to be looked into. Removing request for review.

Is this still an issue? URL is dead. Testcase in comment 14 works fine (though the gif in the testcase is not animated?). Can anyone verify?

Yes, this bug is still present.

*** Bug 243123 has been marked as a duplicate of this bug. ***

The patch doesn't work correctly because it doesn't convert the caret rect from twips to pixels before the intersection with the update region. With a fixed version of the patch, I also see caret turds while scrolling a textarea, and notice that text area scrolling no longer sends ScrollPositionWillChange/ScrollPositionDidChange to the PresShellViewEventListener. Roc, is that a regression from your scrollframe removal?

Ignore the second half of that last comment; I see the pres shell only registers the scroll pos listener on the root scrollable view. It's also the case that the composite listener gets called for scrolls in the textarea, though unclear if that's sufficient to take care of caret drawing.

Another issue here is that nsICaret::GetCaretCoordinates() doesn't clip the caret to its enclosing view, so if the caret in a textarea is scrolled out of view, but overlaps an animated GIF, we'll think we need to redraw it.

Marked bug 290234 as dependant on this one.

*** Bug 260117 has been marked as a duplicate of this bug. ***

*** Bug 299016 has been marked as a duplicate of this bug. ***

This is causing Chinese input unbearably slow in many forums with animated images. I would say this is a very serious bug.

Didn't notice this is a core bug. My previous comment is on the slowness on Camnio.

This is a core bug, but Camino suffers much worse because drawing the caret involves flush of the back buffer to the screen, which is very expensive.

(In reply to comment #39) > This is a core bug, but Camino suffers much worse because drawing the caret > involves flush of the back buffer to the screen, which is very expensive. Yeah.. probably.. This is what I posted for other bug, which is for when writing text becomes very slow... Hi. Well.. I found something interesting. Today's build of Thunderbird, ie. July 24 , has the same problem. There is no noticeable flickering while you are typing email message, but it is very slow. A few days ago, there is no such problem. I didn't add any images in email message. The default style was HTML. Interestingly, the Thunderbird version has some drawing problem. Its Format menu is drawn twice or omitted sometimes. Maybe this redrawing problem is in the core.

*** Bug 302910 has been marked as a duplicate of this bug. ***

*** Bug 304530 has been marked as a duplicate of this bug. ***

I'm just dumping this patch here to archive some changes that might be useful if we want to fix this before the new caret stuff lands. This is a messy, in-progress; don't apply it.

*** Bug 324753 has been marked as a duplicate of this bug. ***

This is working perfectly fine now in my 2006-04-18 trunk build which has the fix for bug 287813. No flickering caret anymore when an animated image is in the page. Marking fixed. Please reopen if this is still an issue in builds later than 2006-04-18.

Verified FIXED using build 2006-04-28-05 of SeaMonkey trunk under Windows XP; no flicker here, either.