Closed
Bug 73725
Opened 24 years ago
Closed 23 years ago
content area flashes/jitters when typing in textarea/using form
Categories
(Core :: DOM: UI Events & Focus Handling, defect, P2)
Tracking
()
VERIFIED
FIXED
mozilla0.9.1
People
(Reporter: bugzilla, Assigned: dr)
References
Details
(Keywords: regression, Whiteboard: want for mozilla 0.9.1)
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.
Reporter | ||
Updated•24 years ago
|
Reporter | ||
Updated•24 years ago
|
Severity: normal → major
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.
Comment 2•24 years ago
|
||
converting dogfood keyword to catfood. Are there other similar bugs still open?
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!
Summary: content area jitters when typing in textarea/using form → content area flashes/jitters when typing in textarea/using form
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.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9
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
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.
Updated•24 years ago
|
Keywords: nsCatFood → nsCatFood+
Comment 7•24 years ago
|
||
->waterson, per hyatt (who sez waterson thinks he broke it), cc hyatt
Assignee: saari → waterson
Status: ASSIGNED → NEW
Comment 9•24 years ago
|
||
This also very occasionally happens to me on Windows 2000. Moving to PC/All.
OS: Linux → All
Updated•24 years ago
|
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
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?
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?
Assignee: joki → evaughan
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.
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.
Comment 16•24 years ago
|
||
*** Bug 77666 has been marked as a duplicate of this bug. ***
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.
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.
Comment 19•24 years ago
|
||
I see this at least once in ~48 hour period, winNT/2k
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.
Reporter | ||
Comment 21•24 years ago
|
||
i still encounter this several times a day.
Updated•24 years ago
|
Target Milestone: mozilla0.9.1 → mozilla0.9.2
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.
Comment 23•24 years ago
|
||
Kin, you rock. Trudelle, Eric, can this *please* be in 0.9.1?
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.
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?
Target Milestone: mozilla0.9.2 → ---
Comment 26•24 years ago
|
||
moving back to 0.9.1. Eric, is this something we could give to arik or dr to fix?
Target Milestone: --- → mozilla0.9.1
Updated•24 years ago
|
Whiteboard: want for mozilla 0.9.1
Comment 27•24 years ago
|
||
*** Bug 79831 has been marked as a duplicate of this bug. ***
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...
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.
Comment 32•24 years ago
|
||
Dan, please resolve both bug reports as fixed when the fix is checked in. Thanks!
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 :)
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 34•24 years ago
|
||
Dan, looks like it's fixed in my Win32 debug build from this morning!!! Thanks!
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).
Comment 37•24 years ago
|
||
Verified on win 2k buildid: 2001062004 works fine. marking verified
Status: RESOLVED → VERIFIED
Reporter | ||
Comment 38•24 years ago
|
||
haven't encountered this bug, either, on linux builds since the checkin.
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.
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.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Comment 41•23 years ago
|
||
Should we change the Target Milestone to some real value, since 0.9.1 was released looong-looong ago?
Comment 42•23 years ago
|
||
The original bug on this issue has been reopened. *** This bug has been marked as a duplicate of 26882 ***
Status: REOPENED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → DUPLICATE
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.
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.
Comment 46•23 years ago
|
||
Re-resolving to FIXED after speaking to jst on IRC and verifying that he was seeing bug 26882.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Updated•6 years ago
|
Component: Event Handling → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•