Closed
Bug 54153
Opened 24 years ago
Closed 19 years ago
Animated image causes textbox insertion point (caret) to flicker
Categories
(Core :: Layout: Form Controls, defect, P3)
Core
Layout: Form Controls
Tracking
()
VERIFIED
FIXED
People
(Reporter: jruderman, Assigned: kinmoz)
References
(Blocks 2 open bugs, )
Details
(Keywords: testcase, Whiteboard: [adt3])
Attachments
(3 files, 2 obsolete files)
7.54 KB,
patch
|
Details | Diff | Splinter Review | |
28.57 KB,
text/html
|
Details | |
20.51 KB,
patch
|
Details | Diff | Splinter Review |
To repro: click in textarea at bottom of http://george-w-dance.homepage.com/ .
Reporter | ||
Comment 1•24 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•24 years ago
|
||
Yep.
Reporter | ||
Comment 5•24 years ago
|
||
This happens with the throbber and the location bar too.
Reporter | ||
Comment 6•24 years ago
|
||
... and with the broken "buddy list" sidebar tab and the location bar.
All pnunn bugs reassigned to Pav, who is taking over
the imglib.
Assignee: pnunn → pavlov
Status: ASSIGNED → NEW
Comment 9•24 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•24 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•24 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•23 years ago
|
||
okay... since the testcase and url no longer works could someone be nice enough
to create another testcase?
Comment 13•23 years ago
|
||
*** Bug 131577 has been marked as a duplicate of this bug. ***
Comment 14•23 years ago
|
||
testcase from bug 131577: attachment 74622 [details]. os->all
OS: Windows 98 → All
Comment 15•23 years ago
|
||
*** Bug 141636 has been marked as a duplicate of this bug. ***
Comment 16•23 years ago
|
||
*** Bug 148087 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 17•23 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•23 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•23 years ago
|
||
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.
Comment 20•22 years ago
|
||
nsbeta1+.
Updated•22 years ago
|
Hardware: PC → All
Comment 21•22 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.
Comment 23•22 years ago
|
||
*** Bug 186542 has been marked as a duplicate of this bug. ***
Comment 24•22 years ago
|
||
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•22 years ago
|
Attachment #113396 -
Flags: review?
Comment 25•22 years ago
|
||
*** Bug 196429 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 26•22 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?
Comment 27•21 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•21 years ago
|
||
Attachment #15504 -
Attachment is obsolete: true
Reporter | ||
Comment 29•21 years ago
|
||
Yes, this bug is still present.
Comment 30•20 years ago
|
||
*** Bug 243123 has been marked as a duplicate of this bug. ***
Updated•20 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•20 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•20 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•20 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.
Comment 34•20 years ago
|
||
Marked bug 290234 as dependant on this one.
Comment 35•20 years ago
|
||
*** Bug 260117 has been marked as a duplicate of this bug. ***
Comment 36•20 years ago
|
||
*** Bug 299016 has been marked as a duplicate of this bug. ***
Comment 37•20 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•20 years ago
|
||
Didn't notice this is a core bug. My previous comment is on the slowness on Camnio.
Comment 39•20 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.
Comment 40•20 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.
Comment 41•20 years ago
|
||
*** Bug 302910 has been marked as a duplicate of this bug. ***
*** Bug 304530 has been marked as a duplicate of this bug. ***
Comment 43•19 years ago
|
||
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. ***
Comment 45•19 years ago
|
||
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.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•