To repro: click in textarea at bottom of http://george-w-dance.homepage.com/ .
Updating QA Contact
QA Contact: paw → tpreston
I'm not clear on the bug symptoms. I see the cursor flicker in the text area. Is that the problem? -p
Status: NEW → ASSIGNED
Target Milestone: --- → M18
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.
Assignee: pnunn → pavlov
Status: ASSIGNED → NEW
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. ***
*** Bug 141636 has been marked as a duplicate of this bug. ***
*** Bug 148087 has been marked as a duplicate of this bug. ***
Assignee: pavlov → rods
Component: ImageLib → 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.
Assignee: rods → kin
Target Milestone: Future → mozilla1.1beta
Created attachment 90696 [details] [diff] [review] W.I.P. Patch 1 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.
Target Milestone: mozilla1.1beta → mozilla1.2beta
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. ***
Created attachment 113396 [details] [diff] [review] W.I.P. patch 1 with some changes 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.
Attachment #90696 - Attachment is obsolete: true
*** 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?
Created attachment 135643 [details] testcase with a non-broken image
Attachment #15504 - Attachment is obsolete: true
Yes, this bug is still present.
*** Bug 243123 has been marked as a duplicate of this bug. ***
Summary: Animated image causes textbox insertion point to flicker → Animated image causes textbox insertion point (caret) to flicker
Target Milestone: mozilla1.4beta → ---
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. ***
Created attachment 193325 [details] [diff] [review] WIP patch (don't apply) 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.
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Depends on: 287813
Resolution: --- → FIXED
Verified FIXED using build 2006-04-28-05 of SeaMonkey trunk under Windows XP; no flicker here, either.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.