204493 - caret leaves turds while scrolling vertically

Status: RESOLVED DUPLICATE of bug 194343

(Core Graveyard :: GFX: Mac, defect)

Description

[sairuh (rarely reading bugmail)]

i've only seen this on Mac OS X. occurs in both editor and the browser (latter
when caret browsing mode is on).

not sure if this is the right component, nor could i find an open bug (simon
demonstrated this issue to me a week or so ago). reassign / dup as needed.

1. open an editor window (or browser window with caret mode on, via F7 key).
2. shrink the height so that the vertical scrollbar appears.
3. go to the top of the document, and place the cursor there (top-leftmost
corner is fine).
4. rapidly hit or hold down the down arrow key to scroll downwards.

results: once the vertical scrollbar moves, the caret doesn't "unpaint" itself
from previous lines --you'll see a nice vertical line remaining.

screenshot coming up.

Comment 1

[sairuh (rarely reading bugmail)]

workaround: once you scroll away (out of view) the portion which contains the
caret turds (grabbing and moving the scroll widget), then the turds go away.

Comment 2

[sairuh (rarely reading bugmail)]

Attachment: screenshot displaying caret turds upon vertical scrolling

note, the caret doesn't have to be in the upper leftmost corner to begin with
in the test case (as seen in this screenshot).

Comment 3

[Jo Hermans]

Isn't this bug 131978 ? It's also mentioned in bug 194343, whose path might fix
this (or not).

Comment 4

[sairuh (rarely reading bugmail)]

i cannot seem to repro bug 131978 on mac os x (tested with 2003.05.05.03 comm
trunk) in html textareas.

Comment 5

[Simon Fraser [no longer active]]

This is different from bug 131978.

Comment 6

[kinmoz]

I tried to reproduce this in my MacOSX debug build from a couple of days ago and
couldn't in Composer. I was able to see turds in the browser (with caret
browsing) while using the up/down arrow keys if the caret ever entered and then
exited a link.

Comment 7

[sairuh (rarely reading bugmail)]

i can still reproduce this in composer with both trunk and 1.4 branch commercial
bits from today (as well as the browser with caret mode on). perhaps this (or,
at least the composer aspect) is a optimized vs debug issue?

Comment 8

[Kathleen :Brade]

I see this in my debug macho build from yesterday.
Steps I use to reproduce:
1) type junk and press return
2) repeat step 1 50 times (or enough to get a scrollbar plus a few lines)
3) press up arrow 50 times
4) press down arrow 50 times

Comment 9

[leon.zhang]

A stack when we type down arrow keys:

nsCaret::DrawCaret() line 944
nsCaret::StopBlinking() line 535
nsCaret::NotifySelectionChanged() line 476
nsTypedSelection::NotifySelectionListeners() line 7831
nsSelection::NotifySelectionListeners() line 3310 + 16 bytes
nsSelection::TakeFocus() line 2863 + 10 bytes
nsSelection::MoveCaret() line 1683 + 44 bytes
nsSelection::LineMove() line 3234 + 16 bytes
PresShell::LineMove() line 3233 + 34 bytes
nsSelectionMoveCommands::DoCommand() line 618 + 36 bytes
nsControllerCommandTable::DoCommand() line 191 + 31 bytes
nsBaseCommandController::DoCommand() line 133
nsXBLPrototypeHandler::ExecuteHandler() line 320
nsXBLWindowHandler::WalkHandlersInternal() line 313 + 24 bytes
nsXBLWindowKeyHandler::WalkHandlers() line 164
nsXBLWindowKeyHandler::KeyPress() line 180
nsEventListenerManager::HandleEvent() line 1631 + 41 bytes
nsWindowRoot::HandleChromeEvent() line 215
GlobalWindowImpl::HandleDOMEvent() line 842
nsXULDocument::HandleDOMEvent() line 1292
nsXULElement::HandleDOMEvent() line 3325 + 46 bytes
nsXULElement::HandleDOMEvent() line 3319 + 60 bytes
nsXULElement::HandleDOMEvent() line 3319 + 60 bytes
nsXULElement::HandleDOMEvent() line 3319 + 60 bytes
nsXULElement::HandleDOMEvent() line 3319 + 60 bytes
nsXULElement::HandleDOMEvent() line 3319 + 60 bytes
nsXULElement::HandleChromeEvent() line 4446 + 39 bytes
GlobalWindowImpl::HandleDOMEvent() line 842
nsDocument::HandleDOMEvent() line 3615
nsGenericElement::HandleDOMEvent() line 1961 + 47 bytes
PresShell::HandleEventInternal() line 6402 + 50 bytes
PresShell::HandleEvent() line 6285 + 25 bytes
nsViewManager::HandleEvent() line 2268
nsView::HandleEvent() line 308
nsViewManager::DispatchEvent() line 2044 + 23 bytes
HandleEvent(nsGUIEvent * 0x0012f77c) line 82
nsWindow::DispatchEvent() line 1054 + 10 bytes
nsWindow::DispatchWindowEvent() line 1075
nsWindow::DispatchKeyEvent() line 2920 + 15 bytes
nsWindow::OnKeyDown() line 3010
nsWindow::ProcessMessage() line 3908 + 36 bytes
nsWindow::WindowProc() line 1337 + 27 bytes

Comment 10

[leon.zhang]

whether we type down arrow keys in composer or browser, we can meet the same
stack above.

Comment 11

[leon.zhang]

I get stack above on windows2000.

I am not very sure whether we can turn off/on in function PresShell::LineMove()
to ensure erase current caret and draw it after linemove.

Comment 12

[leon.zhang]

I think patch(http://bugzilla.mozilla.org/attachment.cgi?id=122356&action=view)
for bug 194343 can resolve this bug.
I test it times. looks ok.

Comment 13

[leon.zhang]

when we move up/down arrow caret and turds happen in mac os, nsCaret::DrawCaret
has been called four times:
1) nsCaret::notifySelectionChanged call DrawCaret 2 times(this can stop current
caret in old pos and start caret in new pos after scroll)
2) StCaretHider in nsTypedSelection::ScrollIntoView will call DrawCaret 2 times.

I have tried to remove the last 2 times of calling to improve perf of caret
process(bug 194343). I comment out StCaretHider line in fucntion
nsTypedSelection::ScrollIntoView, and this bug disappear.

Comment 14

[leon.zhang]

the caret turd is not from timer fire, and you still can reproduce this bug if
you set 100000 to mBlinkRate so that the caret nearly blink.

Comment 15

[leon.zhang]

the caret turd is not from timer fire, and you still can reproduce this bug if
you set 100000 to mBlinkRate so that the caret hardly blink.

Comment 16

[louis bennett]

similar to bug 56913?

Comment 17

[leon.zhang]

*** This bug has been marked as a duplicate of 194343 ***