* Overview: If too many arrowkey presses are used to resize Mozilla's browser window in too short a period, via the Windows control menu (ALT+space,S), such as happens when the key is pressed quickly enough for long enough to queue up the keypress events, rather than resizing monotonically in the direction of that arrowkey, the browser window starts to do a bit of a dance, taking two steps forward, one step back - sometimes several steps back. * Steps to reproduce: 1. View a page with Mozilla, say http://www.mozilla.org/ 2. Activate resizing through the control menu - ALT+space,S (you may run into bug 13372 (page scrolls down) but that won't matter for this testing). 3. Press the right-arrowkey once to select the right border for resizing. 4. Press the left-arrowkey at least a dozen times as fast as you can, enough so that the keypresses queue up. * Actual results: The right border, rather than moving inwards with each keypress in step 4, moves in, then out, then in, etc, in a sort of drunken dance, with the page and (especially) the scrollbar repainting unpredictably. * Expected results: The right border will move in monotonically - perhaps slower than the pace set by the keypresses, but always inward. * Tested with: 2000-01-12-10-M13 nightly binary on Windows NT 4.0sp3, older 120MHz PC * Additional Information: Found while testing bug 13371, "[PP] Win32 - Problems with resizing Apprunner window". The slow resizing speed mentioned there must be part of the problem here; the other part is likely a matter of successively interrupting reflows again and again until all that is done and the display settles on the last non-interrupted reflow. NN 4.7 is just as bad, and IE5 is worse. No other Windows app tried had this problem, but then none of those needed to completely redisplay the entire window contents on each incrment of resizing. Limiting reflows to start not more than once a second, as suggested in bug 13371, would almost certainly help, but that would make keyboard resizing awfully slow (each increment looks like only 8px). The only thing I can think of to prevent the dancing is to simply not allow reflow to be interrupted by keyboard-resizing, but that would be even slower on pathologically slow-to- reflow pages. Nothing like this can be made to happen with mouse-resizing. If mouse-movement of the resizing (double-arrowhead) cursor is too fast for Mozilla, it "gets ahead" of the border, while with keyboard-resizing, the resizing cursor jiggles along the dancing border. Given the realities here, this may be a WONTFIX, but it sure is amusing to test.
Despite that last line, this can't quite be laughed off... with the keyboard-resizing steps so small, it takes a dozen keypresses to move the border 100px, so pressing the arrowkey several times in quick succession is something that could very well happen in real life, not just in testing.
Someone needs to dig into this bug and understand what the cause is. I think we need to start with either the widgets or the app itself
Target Milestone: M15
Move to M16 for now ...
Target Milestone: M15 → M16
Reassigning for Don
Assignee: don → law
Target Milestone: M16 → M18
Move to M21 target milestone.
nav triage team: We're not laughing this off, but we don't think we'll get to this for beta1, marking nsbeta1-
Retesting with 2000-12-23-08 and 2000-12-29-20 on WinNT 4.0, the problem no longer reproduces. Specifically, (a) the window boundary and cursor move smoothly and responsively no matter how fast an arrow key is pressed, even at a autorepeat speed of 30 per second, and, (b) nothing draws inside the Mozilla window while resizing -- only after pressing [Enter] to end the resizing does the page reflow. Observation (b) is completely different that what was seen earlier, when Mozilla would try to reflow after each (8px) window border move. I'm stopping short of marking w.f.m., though, because the problem no longer reproduces in NN 4.7x or IE5, either. It had been just as spectacular there. Given that, someone else should test again in case I've just got a different MS .dll now on this box. BTW, This was always worst for pages with content in nested tables, i.e., where reflow is nontrivial.
Marking nsbeta1- bugs as future to get off the radar.
Target Milestone: --- → Future
Still seeing this with a build from 0417. I'm sure this is due to bug 73823. Marking dependent.
Depends on: 73823
Good call, Dean. There's a very good chance you are right that Bug 73823, "Errant mousemove messages on keyboard navigation?" explains this. I still see this on one WinNT machine using 2001-04-18-04, but not another, where I see the behavior noted in my 2000-12-30 20:16 comment -- so the "no longer reproduces" there only means that some won't see this bug. Guessing that since IE has the same bug, only worse, an IE update (excuse me, Windows Update ;-/) fixed this on the one machine.
Severity: trivial → minor
I'm not seeing this in 2001060604 on Win2000, nor am I seeing behavior b from Sean's 2000-12-30 20:16 comment. Marking worksforme.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME
Quoting from bug 73823: > --- Additional Comments From firstname.lastname@example.org 2001-06-06 19:49 --- > OK, fine. Given that I'm not seeing bug 23936 anymore ... Query: did you ever, on Windows 2000? I've only seen this on WinNT, and it is still happening as of 2001-06-05-09-trunk. REOPENing. Also, the same bug exists in IE5, on the machine that I see it on. On the same machine, NN 4.7 displays fine while resizing -- but it does not redraw as many times as the arrowkey is pressed, if the latter is done quickly enough -- and it also does not "run on" after the arrowkey is let up. Is NN discarding (autorepeat and manual) arrow-keypresses that arrive before each redraw is complete, and would that work for Mozilla too? On two other NT machines, the behaviour is as described in my 2000-12-30 comment: the window contents do not redraw at all until the resize is ended. NN 4.7x and IE (5 & 5.5) (and for that matter Notepad and Telnet) do the same. Supposition: IE had the same bug, and Microsoft fixed it by changing a system DLL to prevent redraws while keyboard-resizing is active, for any app -- kind of a sledgehammer solution -- and this bug will afflict Mozilla instances only if they run on a Windows installation that hasn't had that update.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
You know what, I thought I did, but that may have been on my work machine when it was still NT4. I still think we should catch this at a high level, before dispatching NS_MOUSE_MOVE messages. That would resolve this bug, bug 73823, and any other weird bugs due to these messages. I made a quick C app on Win2000 to watch WM_MOUSEMOVE messages, and I did get a few situations where I was getting the messages when I hadn't moved the mouse. I couldn't reproduce it reliably, though. Perhaps they cleaned this up somewhat for Win2000.
Actually, I _can_ duplicate this on Win2000. What I was doing before was just holding down the left arrow for a couple of seconds. If I instead repeatedly press it, I see the "dance". This almost looks like it may be a layout issue.
Assignee: law → jag
Status: REOPENED → NEW
Priority: P3 → --
QA Contact: chrispetersen
Target Milestone: Future → ---
This bug is being marked EXPIRED as it has seen no activity in a very long time. If you think that the issue reported might still be relevant, please test with a recent release of SeaMonkey and if the problem persists feel free to re-open the report. Thank you. http://www.seamonkey-project.org/
Status: NEW → RESOLVED
Last Resolved: 18 years ago → 10 years ago
Resolution: --- → EXPIRED
Bulk reopening incorrectly expired bugs - no activity does not constitute no bug - these need proper checking.
Status: RESOLVED → REOPENED
Resolution: EXPIRED → ---
Assignee: jag → nobody
Status: REOPENED → UNCONFIRMED
QA Contact: ui-design
WFM=> Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1pre) Gecko/20090621 SeaMonkey/2.0b1pre
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago → 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.