73725 - content area flashes/jitters when typing in textarea/using form

Status: VERIFIED FIXED

(Core :: DOM: UI Events & Focus Handling, defect, P2)

Description

[sairuh (rarely reading bugmail)]

found this using 2001.03.27.08 comm bits on linux. reminiscent of bug 35952, but
alas more difficult that i realized to repro reliably. :(  i don't know when
this regressed precisely, but i've noticed this since y'day's bits...

here's a recipe --if someone can find a more reliable testcase, do let me know!

1. go to any bugzilla bug report page.
2. type something in the Comments textarea.
3. click the View Bug Activity link.
4. click the Back button to return bug report page.
5. try typing in the textarea again. or even changing a radiobutton.

result: the content area of the browser window jitters insanely, making it
difficult to view the page.

Comment 1

[John Morrison]

I think "jitters" is the wrong word. The page scrolls down the height of the 
textarea and right back up in a brief flash. sairuh showed me this on linux,
but it can't be reproduced in current win32 and mac builds.

Comment 2

[selmer (gone)]

converting dogfood keyword to catfood.  Are there other similar bugs still open?

Comment 3

[sairuh (rarely reading bugmail)]

i couldn't find an existing bug like this before i filed --however, if anyone
does know if there are others, pls do add 'em here [or dup this as needed]. thx!

Comment 4

[saari (gone)]

Ah, this is the lovely missing activation problem that usually manifests as
spacebar in a text field scrolling the page.

This was mostly fixed a few weeks ago thanks to blizzard fixing linux widget
code so that it properly fired activate. I'm annoyed, but not surprised to see
it again. This bug can pretty much only be fixed just before shipping because
someone always breaks it within a couple weeks.

Comment 5

[Brendan Eich [:brendan]]

This happened to me today.  Every keystroke entering text into a bug field
scrolled or jittered the page.  This sucks!

saari: why is it so fragile?  I don't think it should be.  There are ways to
keep it from breaking.  Tell us more about what is going wrong.

/be

Comment 6

[saari (gone)]

Fundamentally it is fragile because XP focus management is too damn complicated,
especially in our system. Ours is particularly fragile because focus memory is
forced to keep a semaphore lock on focus when a window becomes deactivated, and
widget is responsible for sending the activate event to unlock it again. That
lock allows focus memory to work correctly when we reactivate a window and flood
of activation and focus messages, both native and xp attack that system. That
flood is different (different events, different sequences) on each OS. To work
around that, the policy is that widget has to fire an activate event into the
system when it is done with the native activate and focus events from the OS.

It might be possible to have the focus controller query the OS itself to see if
the window is active or not, and decide to unlock that way pulling widget out of
the responsiblity loop, but again, what sequence of events happens on each
system will determine if this is possible.

I'm investigating what broke this.

Comment 7

[Peter Trudelle]

->waterson, per hyatt (who sez waterson thinks he broke it), cc hyatt

Comment 8

[Chris Waterson]

No, no, no. I never said that.

Comment 9

[Hixie (not reading bugmail)]

This also very occasionally happens to me on Windows 2000. Moving to PC/All.

Comment 10

[kinmoz]

So I had the pleasure of stumbling onto this bug while in the debugger today, 
and it looks like it might be due to the fact that the mRestore field in 
nsScrollBoxFrame isn't getting reset in some cases. Note, I can't reproduce this 
at will either. :-)

Cc'ing [e-mail]

I stumbled onto it when clicking in the URL bar, typing something, dropping into 
the debugger, continuing, and then clicking into the textarea in a a bugzilla 
bug that was already loaded and visible.

The jitter effect is caused by 2 scrolls, the first one caused by the bug above 
which scrolls the textarea offscreen, and the 2nd one is forced by the editor 
and is expected since we always want to scroll the caret into view.

Below you will find the stack trace of the first (incorrect) scroll. When this 
bug happens nsScrollBoxFrame::DoLayout() (for the browser content area) causes a 
scroll because mRestoreRect has some large non -1 values in it. In the normal 
non-scrolling case, mRestoreRect is full of -1 values so the content area is 
never scrolled.

Here's the stack to the first scroll:


nsWindow::Scroll(nsWindow * const 0x06a2c524, int 0, int -301, nsRect * 
0x00000000) line 2144
nsScrollPortView::Scroll(nsIView * 0x06a2f5e0, int 0, int -301, float 0.0666667, 
unsigned int 0) line 548
nsScrollPortView::ScrollTo(nsScrollPortView * const 0x06a2c6c0, int 0, int 
10890, unsigned int 0) line 328
nsScrollBoxFrame::DoLayout(nsScrollBoxFrame * const 0x00ebfa2c, nsBoxLayoutState 
& {...}) line 502
nsBox::Layout(nsBox * const 0x00ebfa2c, nsBoxLayoutState & {...}) line 985
nsContainerBox::LayoutChildAt(nsBoxLayoutState & {...}, nsIBox * 0x00ebfa2c, 
const nsRect & {...}) line 591 + 16 bytes
nsGfxScrollFrameInner::LayoutBox(nsBoxLayoutState & {...}, nsIBox * 0x00ebfa2c, 
const nsRect & {...}) line 1038 + 17 bytes
nsGfxScrollFrameInner::Layout(nsBoxLayoutState & {...}) line 1143
nsGfxScrollFrame::DoLayout(nsGfxScrollFrame * const 0x00ebf984, nsBoxLayoutState 
& {...}) line 1046 + 15 bytes
nsBox::Layout(nsBox * const 0x00ebf984, nsBoxLayoutState & {...}) line 985
nsBoxFrame::Reflow(nsBoxFrame * const 0x00ebf94c, nsIPresContext * 0x069a1510, 
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) 
line 781
nsGfxScrollFrame::Reflow(nsGfxScrollFrame * const 0x00ebf94c, nsIPresContext * 
0x069a1510, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, 
unsigned int & 0) line 735 + 25 bytes
nsContainerFrame::ReflowChild(nsIFrame * 0x00ebf94c, nsIPresContext * 
0x069a1510, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, int 0, 
int 0, unsigned int 0, unsigned int & 0) line 701 + 31 bytes
ViewportFrame::Reflow(ViewportFrame * const 0x00ebf8d8, nsIPresContext * 
0x069a1510, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, 
unsigned int & 0) line 544
nsHTMLReflowCommand::Dispatch(nsHTMLReflowCommand * const 0x0a821a00, 
nsIPresContext * 0x069a1510, nsHTMLReflowMetrics & {...}, const nsSize & {...}, 
nsIRenderingContext & {...}) line 145
PresShell::ProcessReflowCommand(nsVoidArray & {...}, int 0, nsHTMLReflowMetrics 
& {...}, nsSize & {...}, nsIRenderingContext & {...}) line 5414
PresShell::ProcessReflowCommands(int 0) line 5469
PresShell::FlushPendingNotifications(PresShell * const 0x069e4100) line 4447
PresShell::EndReflowBatching(PresShell * const 0x069e4100, int 1) line 4470 + 15 
bytes
nsEditor::EndUpdateViewBatch() line 4302
nsEditor::EndPlaceHolderTransaction(nsEditor * const 0x0a20dce0) line 712
nsAutoPlaceHolderBatch::~nsAutoPlaceHolderBatch() line 50 + 44 bytes
nsPlaintextEditor::TypedText(nsPlaintextEditor * const 0x0a20dce0, const 
nsAString & {...}, int 0) line 541 + 37 bytes
nsPlaintextEditor::HandleKeyPress(nsPlaintextEditor * const 0x0a20dd74, 
nsIDOMKeyEvent * 0x0a820fb0) line 520 + 34 bytes
nsTextEditorKeyListener::KeyPress(nsIDOMEvent * 0x0a820fb4) line 270 + 41 bytes
nsEventListenerManager::HandleEvent(nsIPresContext * 0x069a1510, nsEvent * 
0x0012f858, nsIDOMEvent * * 0x0012f43c, nsIDOMEventTarget * 0x097298d4, unsigned 
int 7, nsEventStatus * 0x0012f7c4) line 1296 + 23 bytes
nsGenericElement::HandleDOMEvent(nsGenericElement * const 0x08f24bf0, 
nsIPresContext * 0x069a1510, nsEvent * 0x0012f858, nsIDOMEvent * * 0x0012f43c, 
unsigned int 1, nsEventStatus * 0x0012f7c4) line 1500
nsHTMLTextAreaElement::HandleDOMEvent(nsHTMLTextAreaElement * const 0x08f24bf0, 
nsIPresContext * 0x069a1510, nsEvent * 0x0012f858, nsIDOMEvent * * 0x00000000, 
unsigned int 1, nsEventStatus * 0x0012f7c4) line 611 + 29 bytes
PresShell::HandleEventInternal(nsEvent * 0x0012f858, nsIView * 0x06a2f5e0, 
unsigned int 1, nsEventStatus * 0x0012f7c4) line 5214 + 47 bytes
PresShell::HandleEvent(PresShell * const 0x069e4104, nsIView * 0x06a2f5e0, 
nsGUIEvent * 0x0012f858, nsEventStatus * 0x0012f7c4, int 0, int & 1) line 5141 + 
25 bytes
nsView::HandleEvent(nsView * const 0x06a2f5e0, nsGUIEvent * 0x0012f858, unsigned 
int 8, nsEventStatus * 0x0012f7c4, int 0, int & 1) line 377
nsView::HandleEvent(nsView * const 0x06a2c660, nsGUIEvent * 0x0012f858, unsigned 
int 8, nsEventStatus * 0x0012f7c4, int 0, int & 1) line 350
nsView::HandleEvent(nsView * const 0x069dd1e0, nsGUIEvent * 0x0012f858, unsigned 
int 28, nsEventStatus * 0x0012f7c4, int 1, int & 1) line 350
nsViewManager::DispatchEvent(nsViewManager * const 0x069dd380, nsGUIEvent * 
0x0012f858, nsEventStatus * 0x0012f7c4) line 2020
HandleEvent(nsGUIEvent * 0x0012f858) line 68
nsWindow::DispatchEvent(nsWindow * const 0x06a2c524, nsGUIEvent * 0x0012f858, 
nsEventStatus & nsEventStatus_eIgnore) line 695 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f858) line 716
nsWindow::DispatchKeyEvent(unsigned int 131, unsigned short 97, unsigned int 0) 
line 2330 + 15 bytes
nsWindow::OnChar(unsigned int 97, unsigned int 0, unsigned char 0) line 2454
nsWindow::ProcessMessage(unsigned int 258, unsigned int 97, long 1966081, long * 
0x0012fc10) line 2874 + 33 bytes
nsWindow::WindowProc(HWND__ * 0x01a9046e, unsigned int 258, unsigned int 97, 
long 1966081) line 950 + 27 bytes
USE

Comment 11

[saari (gone)]

kin I love you! I would have spent untold hours chasing and sanity checking
focus code looking for this. This should probably be assigned to evaughan rather
than joki then?

Comment 12

[kinmoz]

Heh heh ... your welcome saari. :-)

Yeah, we should probably reassign to evaughan for starters. He may know of some 
things that could trigger this? Could be a bug in the ScrollBox code or even the 
FrameManager which calls RestoreState?

Comment 13

[Peter Trudelle]

->moz0.9.1/p2

Comment 14

[selmer (gone)]

I just had this experience on the 4/18 build using bugzilla on win98.  The
connection to the scrollbar I had was that I had scrolled the page up to the
description box and clicked in it to enter text.  However, the scroll thumb kept
going back to where I had been just before that.  Somehow, the old position was
being remembered somewhere.

Comment 15

[James Green]

I've currently got this happening in another mozilla window, which is allowing
me to type a comment into bug 77676 (which is irrelevant) but with a window
"bounce" effect. It's driving me insane.

Way I got into it:

1) Go to Today's Bug List via bugzilla.mozilla.org link
2) View the bug report, hit back
3) Enter news.com as the URL, hit enter, hit back
4) Enter the bug report again, and start typing

It's forcing the text I type to go to the top of the visible area, and keeps
'bouncing' up and down as type each character, as if it is getting a "Page Down"
but then realising I'm typing something and bouncing me back up to see the text
in the top of the visible area. This is causing my CPU to leap at 50% usage.

I'm seeing this very infrequently, but when it happens, boy do you know it. On
this occassion, I have tried to re-focus the textarea element by switching
desktops, windows, clicking elsewhere, etc., which did the trick in bug 35952,
but not this time.

Comment 16

[Keyser Sose]

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

Comment 17

[Chris McAfee]

saw this on win2k today, just managing my bug list.
This looks bad and is very disconcerting when it happens.

Comment 18

[James Green]

Bah for mid-air collisions... I was just going to say that this seems to have
been more prevalent in the past few days. I've had it twice today, at least once
yesterday... I normally see it maybe once per month.

How frequent is it for the rest of you? It may help identify the severity of
impact and ease of reproduction.

Comment 19

[Chris McAfee]

I see this at least once in ~48 hour period, winNT/2k

Comment 20

[Akkana Peck]

I used to see it at least once a day, usually when I viewed a bug to review it,
clicked on a patch to look at it, then clicked back to add reviewer comments.  I
haven't seen it as frequently in the past week or two as I did in the month
before that, but that may be a type of usage issue.

Comment 21

[sairuh (rarely reading bugmail)]

i still encounter this several times a day.

Comment 22

[kinmoz]

Ok, I know how to reproduce this reliably now. The trick is to get the history
mechanism to "remember" a scrolled position on the page that contains the
textarea. Here's how to reproduce this reliably

1. Go to bug 77558: http://bugzilla.mozilla.org/show_bug.cgi?id=77558
2. Click on the "05/01/01 13:44" attatchment link.
3. Hit the browser back button.
4. Scroll to the very bottom of bug 77558.
5. Hit the forward button.
6. Hit the backward button.
7. Now scroll up to the "Additional Comments" text area and start typing.

You should now see the page jumping around with each letter you type.

The steps may sound a bit long, but it's quite easy to get into this mode when
going back and forth between other pages.

To fix this bug, I think all we have to do is ensure that mRestoreRect gets
cleared after the page has been loaded and scrolled. 

Comment 23

[saari (gone)]

Kin, you rock. Trudelle, Eric, can this *please* be in 0.9.1?

Comment 24

[James Green]

Kin's steps work only if you use your current window thoughout. Don't open the
link in a new window, since the steps don't reproduce the problem in the new window.

Comment 25

[Akkana Peck]

Re trudelle's suggestion, clearing the milestone so that this can be re-triaged
in light of Kin's new information.  Please, can we do this for 0.9.1?

Comment 26

[Peter Trudelle]

moving back to 0.9.1.  Eric, is this something we could give to arik or dr to fix?

Comment 27

[Keyser Sose]

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

Comment 28

[Peter Trudelle]

->dr

Comment 29

[Dan Rosen]

I'll try to fix this along with bug 60584.

Comment 30

[Dan Rosen]

Hm. Seems like the fix for 60584 is the same as the fix for this! Should this be
marked as a dup? Not sure...

Comment 31

[kinmoz]

I think it was gerardok that told me, a long time ago, that if the root of the 
problem between 2 bugs is the same in the implementation, but the symptoms (the 
steps to repro) are different, that we shouldn't dup the 2 bugs, because QA has 
no way of knowing they were related.

Besides if you leave it open, QA will have to test both scenarios, as opposed to 
the one that is described by the bug that everything got dup'd to.

Comment 32

[gerardok]

Dan, please resolve both bug reports as fixed when the fix is checked in. 
Thanks!

Comment 33

[Dan Rosen]

kin, gerardo, thanks for the info. the fix for bug 60584 is checked in, and i'm
resolving this as fixed, but i'm not *positive* it is fixed. gerardo: please
verify with prejudice :)

Comment 34

[kinmoz]

Dan, looks like it's fixed in my Win32 debug build from this morning!!! Thanks!

Comment 35

[Peter Trudelle]

No way of knowing??? Duped bugs are obviously related, they are even 
cross-linked. Netscape QA used to verify resolved dups when the original was 
resolved, some still do and in my opinion all should. Resolving dups as fixed 
falsely skews bugfix statistics, which screws up bug tracking and planning for 
future milestone triage.  Fixed resolution should be as described in A Bug's 
Life Cycle - "A fix for *this bug* is checked into the tree and tested" 
(emphasis added).  

Comment 36

[Madhur Bhatia]

QA contact updated

Comment 37

[Madhur Bhatia]

Verified on win 2k buildid: 2001062004
works fine.
marking verified

Comment 38

[sairuh (rarely reading bugmail)]

haven't encountered this bug, either, on linux builds since the checkin.

Comment 39

[saari (gone)]

Don't be surprised if you see it again. I saw this for the first time in many
moons a day ago, and no, I couldn't reproduce it and I'm not sure how I made it
happen.

Comment 40

[Johnny Stenback (:jst)]

I just saw this one in a trunk build from yesterday, reopening. And no, I
couldn't reproduce it again, but this really doesn't seem fixed.

Comment 41

[Eugene Savitsky]

Should we change the Target Milestone to some real value, since 0.9.1 was
released looong-looong ago?

Comment 42

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The original bug on this issue has been reopened.

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

Comment 43

[kinmoz]

Actually this bug was different from the "space bar in text widget scrolls page"
bug. This bug had to do with the fact that there was some state set from the
session history that wasn't being cleared out. With the original reported bug,
any char you would type would cause the page to jump around.

The original bug was fixed and I believe is still fixed. See comment 22 for
details on how to reproduce the original bug.

Comment 44

[kinmoz]

jst, when you reopened this bug was it because you were scrolling when you hit
the space bar? If so, that's a different bug ... it's bug 26882.

Comment 45

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Reopening then...

Comment 46

[kinmoz]

Re-resolving to FIXED after speaking to jst on IRC and verifying that he was
seeing bug 26882.

Comment 47

[kinmoz]

Restoring VERIFIED status.