Animated image causes textbox insertion point (caret) to flicker

VERIFIED FIXED

Status

()

P3
normal
VERIFIED FIXED
18 years ago
5 years ago

People

(Reporter: jruderman, Assigned: kinmoz)

Tracking

(Blocks: 2 bugs, {testcase})

Trunk
testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [adt3], URL)

Attachments

(3 attachments, 2 obsolete attachments)

(Reporter)

Description

18 years ago
To repro: click in textarea at bottom of http://george-w-dance.homepage.com/ .
(Reporter)

Comment 1

18 years ago
Created attachment 15504 [details]
testcase

Comment 2

18 years ago
Updating QA Contact
QA Contact: paw → tpreston

Comment 3

18 years ago
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
(Reporter)

Comment 4

18 years ago
Yep.

Updated

18 years ago
Target Milestone: M18 → Future
(Reporter)

Comment 5

18 years ago
This happens with the throbber and the location bar too.

Updated

18 years ago
Blocks: 61527
(Reporter)

Comment 6

18 years ago
... and with the broken "buddy list" sidebar tab and the location bar.
(Reporter)

Comment 7

18 years ago
This could be caused by bug 60880.

Comment 8

18 years ago
All pnunn bugs reassigned to Pav, who is taking over
the imglib.
Assignee: pnunn → pavlov
Status: ASSIGNED → NEW

Comment 9

18 years ago
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

Comment 10

18 years ago
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.

Comment 11

18 years ago
Forgot to add...

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

Comment 12

17 years ago
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
OS: Windows 98 → All
Blocks: 119597

Comment 15

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

Comment 16

17 years ago
*** Bug 148087 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 17

17 years ago
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.
Assignee: pavlov → rods
Component: ImageLib → HTML Form Controls
(Assignee)

Comment 18

17 years ago
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
(Assignee)

Comment 19

17 years ago
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.
nsbeta1+. 
Keywords: nsbeta1+
Whiteboard: [adt3]
Target Milestone: mozilla1.1beta → mozilla1.2beta
(Assignee)

Updated

16 years ago
Status: NEW → ASSIGNED

Updated

16 years ago
Hardware: PC → All
(Assignee)

Updated

16 years ago
Target Milestone: mozilla1.2beta → mozilla1.3alpha

Comment 21

16 years ago
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.
(Assignee)

Updated

16 years ago
Target Milestone: mozilla1.3alpha → mozilla1.3beta

Comment 22

16 years ago
Reproduced in 12/16 Trunk build on Win XP
Keywords: testcase

Comment 23

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

Comment 24

16 years ago
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

Updated

16 years ago
Attachment #113396 - Flags: review?

Comment 25

16 years ago
*** Bug 196429 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

16 years ago
Target Milestone: mozilla1.3beta → mozilla1.4beta
(Assignee)

Comment 26

16 years ago
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.
Attachment #113396 - Flags: review?

Updated

16 years ago
Blocks: 194343

Comment 27

15 years ago
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?
(Reporter)

Comment 28

15 years ago
Created attachment 135643 [details]
testcase with a non-broken image
Attachment #15504 - Attachment is obsolete: true
(Reporter)

Comment 29

15 years ago
Yes, this bug is still present.

Comment 30

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

Updated

14 years ago
Blocks: 272954

Updated

14 years ago
Summary: Animated image causes textbox insertion point to flicker → Animated image causes textbox insertion point (caret) to flicker
Target Milestone: mozilla1.4beta → ---

Comment 31

14 years ago
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?

Comment 32

14 years ago
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.

Comment 33

14 years ago
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.

Updated

14 years ago
Blocks: 290234

Comment 34

14 years ago
Marked bug 290234 as dependant on this one.

Comment 35

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

Comment 36

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

Comment 37

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

Comment 38

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

Comment 39

14 years ago
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.

Updated

13 years ago
Blocks: 301774

Comment 40

13 years ago
(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. ***

Comment 43

13 years ago
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.

Updated

13 years ago
Blocks: 262521
*** 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.