sairuh (rarely reading bugmail) Reporter
	Description • 24 years ago

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.

	John Morrison
	Comment 1 • 24 years ago

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.

	selmer (gone)
	Comment 2 • 24 years ago

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

	sairuh (rarely reading bugmail) Reporter
	Comment 3 • 24 years ago

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!

	saari (gone)
	Comment 4 • 24 years ago

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.

	Brendan Eich [:brendan]
	Comment 5 • 24 years ago

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

	saari (gone)
	Comment 6 • 24 years ago

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.

	Peter Trudelle
	Comment 7 • 24 years ago

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

	Chris Waterson
	Comment 8 • 24 years ago

No, no, no. I never said that.

	Hixie (not reading bugmail)
	Comment 9 • 24 years ago

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

	kinmoz
	Comment 10 • 24 years ago

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 evaughan@netscape.com

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

	saari (gone)
	Comment 11 • 24 years ago

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?

	kinmoz
	Comment 12 • 24 years ago

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?

	Peter Trudelle
	Comment 13 • 24 years ago

->moz0.9.1/p2

	selmer (gone)
	Comment 14 • 24 years ago

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.

	James Green
	Comment 15 • 24 years ago

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.

	Keyser Sose
	Comment 16 • 24 years ago

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

	Chris McAfee
	Comment 17 • 24 years ago

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

	James Green
	Comment 18 • 24 years ago

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.

	Chris McAfee
	Comment 19 • 24 years ago

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

	Akkana Peck
	Comment 20 • 24 years ago

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.

	sairuh (rarely reading bugmail) Reporter
	Comment 21 • 24 years ago

i still encounter this several times a day.

	kinmoz
	Comment 22 • 24 years ago

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. 

	saari (gone)
	Comment 23 • 24 years ago

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

	James Green
	Comment 24 • 24 years ago

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.

	Akkana Peck
	Comment 25 • 24 years ago

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?

	Peter Trudelle
	Comment 26 • 24 years ago

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

	Keyser Sose
	Comment 27 • 24 years ago

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

	Peter Trudelle
	Comment 28 • 24 years ago

->dr

	Dan Rosen Assignee
	Comment 29 • 24 years ago

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

	Dan Rosen Assignee
	Comment 30 • 24 years ago

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

	kinmoz
	Comment 31 • 24 years ago

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.

	gerardok
	Comment 32 • 24 years ago

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

	Dan Rosen Assignee
	Comment 33 • 24 years ago

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 :)

	kinmoz
	Comment 34 • 24 years ago

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

	Peter Trudelle
	Comment 35 • 24 years ago

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).  

	Madhur Bhatia
	Comment 36 • 24 years ago

QA contact updated

	Madhur Bhatia
	Comment 37 • 24 years ago

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

	sairuh (rarely reading bugmail) Reporter
	Comment 38 • 24 years ago

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

	saari (gone)
	Comment 39 • 24 years ago

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.

	Johnny Stenback (:jst)
	Comment 40 • 23 years ago

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.

	Eugene Savitsky
	Comment 41 • 23 years ago

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

	David Baron :dbaron:
	Comment 42 • 23 years ago

The original bug on this issue has been reopened.

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

	kinmoz
	Comment 43 • 23 years ago

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.

	kinmoz
	Comment 44 • 23 years ago

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.

	David Baron :dbaron:
	Comment 45 • 23 years ago

Reopening then...

	kinmoz
	Comment 46 • 23 years ago

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

	kinmoz
	Comment 47 • 23 years ago

Restoring VERIFIED status.