Name: mc57594 Date: 01/28/97


The following demo code shows how the scrollbars on Win95
tend to get stuck. It's as if they don't catch a MOUSE_UP, so they act
as if the mouse button were stuck down. If you move the mouse
out of the scrollbar, the events pause, but they resume if the mouse
reenters the scrollbar.

The way to cause it to go bonkers is to start clicking rapidly. That's
all it takes. It works (or I should say it fails) 100% of the time if
you just send it a quick stream of clicks. If you click the mouse
repeatedly again, you can usually break it out of its loop, and the
scrollbar stops scrolling itself.

The scrollbars in Java 1.0.2 were so flaky, I was really looking forward
to Java 1.1beta1, then beta2, then beta3. No other scrollbar on my
machine has this problem, only those in Java. Please give us sane scroll
bars, or at the very least, please acknowledge that the problem exists
on your known bugs page! You may think that some other bug such as
"textareas not responding to double-click" are actually the same bug,
but I hope you'll add this to the known-bug list just in case they
aren't the same problem. You can't afford to miss this one. I can't ship
a product whose scrollbars get stuck scrolling themselves as if the
mouse button were being held down. Unless you fix this one, we're stuck
with an unshippable product.

Use the following code to reproduce it. Thanks.

Here's the code to 'Scroller.java'----------------------------

import java.awt.*;

public class Scroller extends Frame
{
    TextField tf;
    Scrollbar sb;

    public static void main(String[] args)
    {
        Frame f = new Scroller();
        f.resize(320, 200);
        f.show();
    }

    public Scroller()
    {
        setTitle("Scrollbar Bug");
        setLayout(new BorderLayout());

        tf = new TextField("");
        sb = new Scrollbar(Scrollbar.HORIZONTAL, 0, 0, 0, 10000);

        add("Center", tf);
        add("South", sb);
    }

    public boolean handleEvent(Event evt)
    {
        if(evt.id == Event.WINDOW_DESTROY) System.exit(0);
        else if(evt.target == sb)
        {
            //System.out.println("Scrollbar value = "+sb.getValue());
            System.out.println("Event = "+evt);
            tf.setText(Integer.toString(sb.getValue()));
        }
        else super.handleEvent(evt);

        return true;
    }


}

// end of Scroller.java---------------------------------------
======================================================================

 1997-02-12

Several other people submitted the same bug. One example follows:
-mark chamness-

==============================================================

From: ###@###.###

Synopsis: scroll bars not handled correctly; possible event handling problem

Description: I noticed this bug in the "Converter" program included in the
tutorial.

1) In the "Converter" program in the tutorial, you can
   click the first scroll bar and, some times, the
   event "sticks", so the scroll bar remains highlighted. You
   can then move to the second scroll bar and the first one
   will change to an odd shape.

2) If you move to the right side of one of the scroll bars thumb
   tabs, you can click and, again, the event will "stick" and
   the value will continue to change. It is most prone to
   occuring if you double click in the scroll bar (not on the
   tab or one of the arrows). It can also do one of two things.

   case 1:
   Sometimes, the scroll area to the right will remain darkened
   and the number will continue to increase, even though you
   aren't clicking. It will stop if you move out of the scroll
   bar, but continue if you simply move back into the area.

   case 2:
   Sometimes, the scroll area will return to it's "unclicked"
   grey color, but the number will continue to change. This
   time, it's DECREASING, not increasing. If you move outside
   the scroll bar, the entire area between the thumb tab and
   the right arrow button will change into one large left arrow
   button. It's rather odd looking. In either case, you can
   click once inside the scroll bar to stop it, but that won't
   keep it from occuring again later.

   The first case *seems* to be caused by double clicking.
   The second case seems to FOLLOW the first. If you double
   click and cause the first case to occur, waiting a split
   second and single clicking in the same area can cause the
   second case.

   Further note: If you perform the first case on the LEFT
   side of the tab, it behaves as you would expect. The
   number will decrease constantly (whereas on the right side
   it increases constantly). On the second case, the number
   decreases constantly no matter which side of the tab you
   do it on.
   
3) In the "GUIWindow" demo program, you can type in a text field
   all the way out to the side and the thumb tab on the
   horizontal scroll bar will decrease in size. However,
   deleting the text doesn't make it increase again. The
   vertical scroll bar tab seemed to work ok, though.

4) Again, in the "GUIWindow" demo, if you maximize the screen,
   then reduce it again, sometimes the window doesn't redraw
   correctly. I could only duplicate this once.

5) The scroll bars lag terribly. As you move the bar,
   it races to catch up with you.

6) Over text fields, the cursor flickers from "I-beam" to
   "pointer" and back rapidly as you move. It seems the code
   is checking events constantly. I do not notice this using
   other applications, though I imagine they must also check
   events to see what kind of cursor should be displayed.
   Although there is a *slight* flicker in those other apps,
   it never changes to another cursor type as it does with
   java apps. I get the feeling that events aren't being
   handled correctly.

I wish I knew more about the internals of things so I could
offer some kind of workaround or provide more useful
information, but I'm just learning Java as it is.
Perhaps these have already been reported (or fixed in some
future release), and I would like to know the status of
these "bugs". (Maybe they're not and the system is just supposed
to work that way... I've had that happen before. Usually,
it's just a matter of me thinking it should work differently.)
;)

For the record, I'm running a DEC PC 486/33 (originally), but
I added a DX2/80 processor (which will only run at 66 due to
motherboard limitations), with 24 mb ram. I replicated the
errors through netscape and through the included JDK
appletviewer.
company - University of Arkansas at Little Rock , email - ###@###.###

Release: jdk11beta3
Hardware Version: i586
O/S version: win_95