Closed Bug 23936 Opened 25 years ago Closed 15 years ago

[WIN32] Queued arrowkeys after ALT+space,S cause 'dance'

Categories

(SeaMonkey :: UI Design, defect)

Product:
SeaMonkey
Component:
UI Design
Platform:
x86
Windows NT
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: sidr, Unassigned)

References

(
URL
)

Details

(Keywords: access) 

* 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.
Assignee: troy → don
Component: Layout → XPApps
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
post-beta
Target Milestone: M15
Move to M16 for now ...
Target Milestone: M15 → M16
Reassigning for Don
Assignee: don → law
Target Milestone: M16 → M18
Target Milestone: M18 → M21
Move to M21 target milestone.
Keywords: nsbeta1-
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
Keywords: access
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
Closed: 23 years ago
Resolution: --- → WORKSFORME
Quoting from bug 73823:
 >  --- Additional Comments From dean_tessman@hotmail.com  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.
Product: Core → Mozilla Application Suite
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
Closed: 23 years ago → 15 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
Closed: 15 years ago → 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.