144018 - Up/Dn Arrows Randomly Act Like PgUp/PgDn

Status: RESOLVED FIXED

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

Description

[Felix Miata]

2002051109 OS/2 trunk
not new

To reproduce:
1-This is unclear, as the behavior as near as I can tell is random. Prerequisite
seems to be a long page. I can't tell if pure text is enough, or whether
embedded images are required. I've seen it off and on for well over a week. When
I first visited the reference URL (today for first time), there was #TAB25
appended to it, which may also be required to observe the behavior. This does
not appear to be the same behavior as bug 11751 or 25054. After reaching the
bottom of the page for the first time, the behavior ceased, so to duplicate
might require intentionally not reaching the bottom of the page before observing
several instances of the errant behavior. I'm not sure where to look for another
page to cause the same behavior. IIRC, I have seen it in Mozilla show_bug pages,
but couldn't find one since trying to draft this bug submission.
2-Press and hold either up or down arrow enough to scroll somewhere between half
a pane and a full pane. Repeat, repeat, repeat, etc.

Actual behavior:
1-pane randomly scrolls a full pane or more in a jump among otherwise smoothly
melded line advances, causing overshoot

Expected behavior:
1-pane scrolls smoothly up/down one half to one full pane, stopping precisely
when the key is released

Comment 1

[Mike Kaply [:mkaply]]

In your preferences for mouse scrolling, what is it set to?

Comment 2

[Felix Miata]

Scroll a page up or down, but no moving objects during the behavior are anywhere
near a mouse.

Comment 3

[Felix Miata]

Happened again a little bit ago on bug 131037 and bug 41924 using 2002051208.

Comment 4

[Mike Kaply [:mkaply]]

Can you change your scrollmouse preferences to make the font bigger instead of 
do page up and page down and then see if the behavior changes?

I'm trying to see if this is caused by the code that us being used to try to 
detect when a scrollmouse is used.

Comment 5

[Mike Kaply [:mkaply]]

Incidentally, I haven't been able to recreate it.

Comment 6

[Felix Miata]

I'll have to remember to make the pref change upon finding it happen again,
since it cannot be duplicated at will.

Any chance that video driver or hardware could impact this? Using SDD Pro GA
with  ET6100 here. MVP3 chipset.

Comment 7

[Felix Miata]

Another URL: http://www.w3.org/TR/WCAG10-CSS-TECHS/

Observed reported behavior very infrequent and random, then changed mouse wheel
pref from "scroll a page . . ." to "make the text . . .", and again observed the
reported behavior.

Comment 8

[Mike Kaply [:mkaply]]

Are you hitting the down arrow repeatedly?

Upon further reading here, I believe you are just getting ahead of the scroll 
buffer.

If you go to any long page, start at the top, and hit the down arrow really fast 
and then stop, the page will keep scrolling as it catches up with the number of 
keys you hit.

Comment 9

[Felix Miata]

Nothing like what you describe. I could never repeat stroke any key quick enough
to provide the apparent smooth scroll I described. My BIOS is set to keyboard
250 delay and 20 CPS. This is what is required to make DOS apps perform
acceptably whether DOS is booted or run in OS/2 DOS session. I simply hold
("press and hold") the key down for a period, then release. The problem is that
often on a page where I have seen the behavior I can try to reproduce by holding
the key down long enough to scroll the whole page both ways twice or more and
yet not see the errant behavior repeat itself. It is very random and usually
very infrequent. On the URL indicated, when first visited, the behavior
manifested at least a dozen times, but has not once since returning.

Comment 10

[Mike Kaply [:mkaply]]

If you hold down any key for any period of time, it can cause the keys to 
buffer. If I go to a long page and scroll to the top. Then hold down the down 
arrow for a second or two and then release, the page will continue to scroll.

Are you seeing the page jump like page up or page down was hit or continue to 
scroll?

Comment 11

[Felix Miata]

You seem to be trying to get me to describe the overshoot I've often seen
scrolling using IE (or other apps displaying scrollbars) and windoze, where
after mouse button or arrow key release, the screen continues to scroll. That I
don't ever see using OS/2.

If I hold the Up/Down arrow key down as long as it takes to pronounce
"one-thousand-one, one-thousand-two", the screen scrolls less than 2-5 lines
more than using the PgUp/PgDn key once (barely more than one paneful). It
doesn't matter whether I hold it down that long, half that long, or many times
that long, the scrolling stops within a tiny fraction of a second of releasing
the arrow key, for all practical purposes, instantly.

When scrolling normally (without any jumps), the scroll speed appears to be
identical to holding the left mouse button down on one of the arrows at the end
of the scrollbar.

The errant behavior when observed is as if one of the up or down arrow
"keypresses" in the continuous string of them created by holding the key down
had been replaced with a PgUp or PgDn keypress. So, yes, when it does happen,
the screen jumps once in the midst of scrolling smoothly.

Last Sysbench run provided as follows:

Video data
Resolution         = 800x600x16 bits/pixel
Number planes      = 0
Screen Access      = Direct
Bank Switched      = No
Bytes/scanline     = 1600
Aperture size      = 4194304
Manufact. code     = 3
Chipset code       = 12808

 Graphics
   BitBlt S->S copy      :       83.485    Million pixels/second
   BitBlt M->S copy      :       39.177    Million pixels/second
   Filled Rectangle      :      290.498    Million pixels/second
   Pattern Fill          :      289.149    Million pixels/second
   Vertical Lines        :        8.263    Million pixels/second
   Horizontal Lines      :       81.072    Million pixels/second
   Diagonal Lines        :        2.525    Million pixels/second
   Text Render           :       63.042    Million pixels/second
   -----------------------------------------------------------------------
   Total                 :      103.911    PM-Graphics-marks

 Direct Interface to video extensions - DIVE
   Video bus bandwidth   :       72.690    Megabytes/second
   DIVE fun              :      274.356    fps normalised to 640x480x256
   M->S, DD,   1.00:1    :      263.260    fps normalised to 640x480x256
   -----------------------------------------------------------------------
   Total                 :       98.090    DIVE-marks

Comment 12

[Mike Kaply [:mkaply]]

Well then I don't know how I would ever track this down. This bug will just sit 
here and languish.

Comment 13

[Felix Miata]

Is your BIOS repeat and delay set to the defaults? Is there a way for OS/2 to
override these?

Comment 14

[Felix Miata]

Another place observed:
http://style.cleverchimp.com/font_size_intervals/altintervals.html

Comment 15

[Felix Miata]

Using 2002051716 branch, another place observed:
http://www.westciv.com/style_master/academy/css_tutorial/index.html

Comment 16

[Felix Miata]

Again with 2002052408 branch at bug 146951 after application of XR_D003 beta and
standard mouse driver instead of AMOUSE.

Comment 17

[Felix Miata]

And bug 135239. Really annoying.

Comment 18

[Felix Miata]

1.0 just did it on a Mozilla bug search results page with 284 hits.

Comment 19

[Kai Lahmann (is there, where MNG is)]

can you still reprocude this with mozilla 1.1beta?

Comment 20

[Felix Miata]

Still happens in 2002080808 OS/2 trunk. No rhyme or reason to it. Very annoying.

Comment 21

[Mike Kaply [:mkaply]]

Without rhyme or reason, I don't know what to do with this.

I set my keyboard setting to exactly the same as yours and never saw the 
problem. I believe you are the only person that has ever seen this.

Can you post on the newsgroups to check on this please?

Comment 22

[Felix Miata]

2002082508 OS/2 trunk. Problem continues at
http://sportsillustrated.cnn.com/football/college/news/2002/08/24/fsu_isu_ap/

Comment 23

[Felix Miata]

Very bad at http://mozilla-evangelism.bclary.com/evangelism.html with 2002082608
OS/2 trunk.

Comment 24

[Felix Miata]

In 2002090308 trunk this also happens reading HTML email.

Comment 25

[Mike Kaply [:mkaply]]

So what do you want to do with this bug?

You are the only one on the planet that sees it.

It seems pretty silly to keep this open for basically no reason.

Comment 26

[Felix Miata]

I thought about this and decided I haven't seen the behavior since buying a new
monitor and switching from 800x600 to 1024x768 over a month ago. I started
visiting in order all the URL's I previously provided here, and thought it would
be a worksforme until I reached bug 135239, where it happened yet again.
Possibly noteworthy is that default font is sans helv and page fonts are disallowed.

What to to? Maybe set a 1.4 milestone and I'll look again as I did just now. If
it hasn't happened in the wild again between then and now, and I only find one
in ten pages it still happens on I'll mark worksforme.

Comment 27

[Felix Miata]

Just happened again at bug 129399 in 2002111612 OS/2 trunk.

Comment 28

[Mike Kaply [:mkaply]]

This issue is not whether or not it happens. Clearly it happens to you.

The issue is that you are the only person on the entire planet to see this problem.

So keeping a bug open seems silly. Have you seen on any other OS/2 machine?

Comment 29

[Felix Miata]

Still happening. Another URL: http://www.iarchitect.com/tabs.htm

Comment 30

[Felix Miata]

Reading bug http://bugzilla.mozilla.org/show_bug.cgi?id=90198#c59 I found
http://anomaly.hrunting.org/old.html. In vacpp 1.4 branch 20030629 about as many
times as not a single up or down arrow results in a PgUp or PgDn. It only takes
5-6 sequential ups or downs to scroll the entire page. All the while on the
page, the CPU is on 100%.

I got my eCS 1.1 disks Friday, so should be trying this soon on a fresh OS install.

Comment 31

[Felix Miata]

I replaced my K6/2-550 CPU with a K6/3-550+ CPU, and MCP with eCS 1.1 over the
last several days. I've switched to 1280x960 resolution. This still happens in
trunk on http://style.cleverchimp.com/font_size_intervals/altintervals.html
(tables) consistently, and on The Register (also tables) news article and
various pages on other sites, though not on any of the URL's I provided here
previously. The original URL here doesn't currently have any content to scroll.

I expect to be upgrading to an Athlon XP box soon. It's mostly together already,
assuming I don't sell it first. I'll be looking for pages that do this built
with css instead of tables over the next few days using this new OS install.

Comment 32

[Felix Miata]

I now have a Celeron 2400 on Intel 865PE chipset system. Other than the newer
and different hardware, the new system does have a possibly relevant BIOS
setting difference. New motherboards seem to have abandoned the previous options
to set the keyboard delay and repeat rate, which on all my Socket 7 systems I
set to 20cps & 250ms. On my Linux systems I repeat the BIOS settings in .bashrc
with 'kbdrate -r 20 -d 250' or with comparable settings in /etc/sysconfig/keyboard.

Of all the URLs I provided in previous comments, all but two behave properly
now. Those that behave properly are tables pages. 

http://www.w3.org/TR/WCAG10-CSS-TECHS/ (53K, css =
http://www.w3.org/TR/WCAG10-CSS-TECHS/style/default.css &
http://www.w3.org/StyleSheets/TR/W3C-NOTE) &
http://www.westciv.com/style_master/academy/css_tutorial/ (27K, css =
http://www.westciv.com/style_master/house/house.css &
http://www.westciv.com/style_master/house/real_house.css) still exhibit errant
behavior, but different from before with the slower machine.

I opened each in separate new tabs, followed after testing for the errant
behavior, by saving the pages to disk to locate the CSS urls and then load them
into the same two tabs.

W3 includes in css:
background-image: url(http://www.w3.org/StyleSheets/TR/logo-NOTE);
background-position: top left;
background-attachment: fixed;
background-repeat: no-repeat;

Westciv includes in css:
background-image: url(images/decor/ellipses.gif);
background-position: top left;
background-attachment: fixed;
background-repeat: repeat;

What happens now is that as long as the up or dn keys are depressed (which if
done long enough overflows the buffer, beeping the speaker), the scrolling
proceeds at a steady jitter slow enough for the eyes to follow. As soon as the
key is released, the balance of the full/nearly full keyboard buffer seems to be
unleashed all at once. At that point rather than jumping instantly far up or
down the page as before, the page is swiftly scrolled to that point, still as if
the pgup or pgdn keys had been substituted for the up or dn keys.

There is a further reproduction quirk. After loading the css for those pages in
the same two tabs, returning to them resulted in normal behavior for both. I
next loaded them in new tabs, and the errant behavior was again present. I came
back here to write further, then returned to the newer tabs, and the behavior
was gone. I came back to write again, returned again, and in one the behavior
was gone, while in the other it remained.

Each time I open either in a new tab, the errant behavior is present. What
happens next I just don't know how to describe any better than above.

Attempting to reproduce the above in the Linux trunk (Socket 7 with 20/250 in
BIOS and /etc/sysconfig/keyboard), the keyboard buffer appears to unload at
exactly the same rate even after the up or dn keys are released. That is, the
scrolling will continue at the same rate after the key is release as before,
continuing until the buffer is empty. (see
http://bugzilla.mozilla.org/show_bug.cgi?id=90198#c15)

Comment 33

[Felix Miata]

Using 2004031508 in my old K6/3-550 machine, behavior is substantially the same
as described as in comment 32. Differences are:

1-quite obviously everything is slower on the background-fixed pages

2-the bad behavior is always reproducable. Leaving the page or tab and returning
never halted the bad behavior.

3-the keyboard buffer after only a short period (2 sec maybe?) of a single
downstroke stores enough keystrokes that upon release of the key the swift
scrolling does not end until the page extreme is reached. 

Comment 34

[Mike Kaply [:mkaply]]

When I fill up the buffer and then release, the page continues to scroll at the
same rate. I never see any major jump.

Comment 35

[Felix Miata]

I just spent most of the past 10 hours working this.

I duplicated the behavior in comment 32 and comment 33 with an Intel i810e
chipset motherboard, 128M RAM & 800 Celeron. I first used a clone of my Dec 2003
boot partition (MCP w/ FP2) with the same video card, then with the onboard
Intel video. Next I used the disk from the PC my new one replaced a month ago
(eCS 1.1 w/ no fixpaks) with the onboard video.

Then I tried a brand new profile. That eliminated the problem, so most of the
time I spent trying to find out which file was dirty. I moved the disk back to
the old PC and used that. I added files from my regular profile to the new
profile, user css files first, then user.js. No impact, so next I began changing
various prefs, and eventually gave up that method. Next I went to my regular
profile and deleted all rdf files and xul.mfl to no effect.

Then I copied prefs.js from my regular profile to the new, and edited the
absolute paths before using it. That brought the dirty back, so something in
prefs.js is responsible. Whatever is in there to cause it can't be an isolated
thing, because since opening this bug I've created a new main profile several
times, 3 minimum. 

Comment 36

[Mike Kaply [:mkaply]]

Can I get the prefs.js that causes the failure?

You can send it directly to me.

Comment 37

[Mike Kaply [:mkaply]]

I understand what is happening!

this code:

http://lxr.mozilla.org/seamonkey/source/widget/src/os2/nsWindow.cpp#2210

If the buffer fills up, we continue to get keystrokes but the key isn't held
down. So when we check the physical keystate, we think it is a scroll mouse message.

Felix has his scroll mouse set to pageup/pagedown by default.

The reason we have this code is because some crappy mouse drivers on OS/2
emulate the scroll function with arrow keys instead of WM_HSCROLL and WM_VSCROLL.

Any suggestions on what to do would be welcome. I'm considering removing the code.

Unfortunately the checkin comment was wrong and I can't find the original bug
for which I checked in that code.

We need to look at amouse and the IBM driver.

Comment 38

[Mike Kaply [:mkaply]]

bug 119303 caused this.

Comment 39

[Mike Kaply [:mkaply]]

Attachment: Fix for problem

If repeat count is > 0, it can't be from the mouse.

Comment 40

[jhp (no longer active)]

Comment on attachment 145526 [details] [diff] [review]
Fix for problem

Could you please add a nice comment before that if statement?  Otherwise, r=

Comment 41

[Mike Kaply [:mkaply]]

Fix checked in with comment.

I put it in 1.4 for good measure.

Comment 42

[Felix Miata]

verified fixed in trunk, but no 1.4.2 builds on the mirrors since the checkin

Comment 43

[Felix Miata]

verified fixed in today's 1.4.2

Comment 44

[Mike Kaply [:mkaply]]

Attachment: Supplemental fix

OK, so repeat is set if Ctrl or Alt is down, so this broke modifier keys with
the IBM single mouse driver.

Note that with amouse, modifiers have always been broke.

Comment 45

[Mike Kaply [:mkaply]]

Reopen for regression so I don't lose track of it.

Comment 46

[Mike Kaply [:mkaply]]

Comment on attachment 146865 [details] [diff] [review]
Supplemental fix

Javier already saw this and reviewed it on my machine.

sr=blizzard (platform specific)
a=mkaply (OS/2 only)

Comment 47

[Mike Kaply [:mkaply]]

Regression fix checked in.