Closed Bug 219805 (Autoscroll/win32) Opened 21 years ago Closed 21 years ago

autoscroll not implemented -- accessibility or GUI feature

Categories

(SeaMonkey :: UI Design, defect)

x86
Windows 98
defect
Not set
major

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 22775

People

(Reporter: mozilla, Unassigned)

Details

User-Agent:       lynx 5.5 (vision impaired version)
Build Identifier: V1.3

As someone with accessibility issues; (ulnar nerve, @C8 nerve bundle & cubital
tunnel), applying pressure to a mouse (clicks) is more painful than rolling
around a trackball that requires no finger motion. 

I wasn't sure if this belonged under accessiblity...but it seems to be a window
widget implementation.

For an initial solution, I'd suggest fixing it on the OS's that natively 
support it (win32) using the native invocation method (middle mouse click,
scroll-wheel click, or simulated middle-mouse click via simultaneous right and
left mouse clicks).  

I would suggest for compatibility, if over a link, behave as current (open new
window), else, activate scrolling function.  It's perfectly acceptable to have
different functionality based on whether over link or not: example, SELECT, over
link opens link in same window, over text, starts the beginning of a select text
operation.  Same idea....

Note, I removed the depends on 63712, since it is not reasonable to have to
first decide how to implement this on all OS's simply to provide equivalent
functionality that IE has had since V4 on Windows.  I don't like the
non-equivalency, but some OS's have more advanced toolkits/UI interfaces.  It
doesn't make sense to block native OS features on one platform because another
OS doesn't provide it.  You don't get to be best of breed on an OS by dumbing
down to the lowest common denominator of all OS's the product is supported on.

That's why I was tempted to label this as an Accessibility issue -- since there,
it's quite clear that the goal is to use the native accessibility features when
available -- not wait for the same accessibility features to become present on
all OS's.

If cross-OS politics become or continue to be a problem blocking this bug's fix,
I'll move it to Accessibility, since for me, and anyone with RSI's (Repetitive
Stress Injuries) or RSD's (...Disabilities), it is an accessibility issue.

I used to run native Linux desktop before my RSI's forced me over to Windows.
I still do development on Linux, but I use a windows laptop to log into the 
server or edit files over SMB (setup Linux box as Domain Master).

I chose Win98 as listed OS, since it is the lowest versioned OS that I know
supports this feature, but it's really for OS's up through Win2003 Server (there
doesn't seem to be a way to specify win32 as a platform nor choose multiple
OS's).


The following URL describes the behavior and contains sample C code to 
implement "autoscrolling":

http://www.microsoft.com/msj/1297/visualprog1297.aspx

IntelliMouse Panning

Panning is a really nice feature. You move around your document by holding down
the mouse wheel and moving the mouse to "pan" the document in the direction of
the mouse movement. In Microsoft Excel, panning lets you zip to the bottom-right
corner of your spreadsheet very quickly without ever having to click a scroll
bar. The speed of the pan is controlled by the distance of the cursor from where
you started panning. Try panning in Microsoft Excel or Word and you'll see what
we mean. 
As part of the IntelliMouse specification, Microsoft also defines a variety of
cursors to be used in IntelliMouse panning. For example, when a user clicks the
mouse wheel to initiate scrolling or moves the cursor back to the neutral zone
(the area around the panning origin), one of three standard cursors appears,
telling the user what level of panning support is provided.  

    ^
   <o> Indicates when two-dimensional panning is supported.  
    V

    ^
    o Indicates that vertical-only, one-dimensional panning is available.  
    V
 
 <-o-> Indicates that horizontal-only, one-dimensional panning is available 

During panning there are four cursors (eight if you support diagonal panning)
that show the direction of the panning:  
<o West   o> East  

 ^
 o North   o South 
           V
 
The panning support in many Microsoft IntelliMouse-compatible applications is
dramatically different. For example, Microsoft Excel and IE 4.0 implement
panning by creating the panning origin wherever the mouse happens to be (see
Figure 1). Word, on the other hand, implements only vertical panning and moves
the panning origin relative to the vertical scroll bar (see Figure 2). If you
plan on supporting only vertical scrolling, it may be a good idea to create a
CScrollBar derivative that handles the panning and scrolling so you can isolate
the support from your application. It seems like this is the approach taken by
the Word team. 
 
IntelliMouse AutoScroll 

In the IntelliMouse specification, an application should enter Autoscroll mode
when the user clicks the mouse wheel but doesn't drag it. 

>>>>> IE 4.0 has the smoothest implementation of this. It basically lets the
user start the windows scrolling and then continues to scroll until the user
moves the mouse or clicks another button. <<<<<

This is useful for applications like Word where the user may want to read large
volumes of vertical text, but does not want to scroll manually.
CScrollView meets only one requirement of the IntelliMouse specification葉hat
the view scrolls when the user moves the mouse wheel. This is largely because
CScrollView does not support zooming or panning. This month we will implement a
CScrollView derivative called MSJSuperView that supports zooming and panning
with the IntelliMouse. Before we can add IntelliMouse zooming and panning
support, however, we need to add zooming and panning support to the CScrollView. 
 

IntelliMouse Panning 

The tricky part about implementing IntelliMouse panning is the display of the
panning cursors. You have to display both the origin and directional cursors
while the user is panning. Since Windowsョ has only one cursor, this is pretty
daunting. To solve this problem, let's use the normal Windows cursor for the
directional panning and then create a special window to display the origin.
The origin window is called MSJMouseWheelOriginWnd (see Figure 7). It is
basically a very small CWnd derivative that implements some custom painting to
draw a transparent origin bitmap so that the bitmap can be seen through and
doesn't affect scrolling.
The MSJMouseWheelOrigin takes the resource ID for the bitmap to draw at the
origin. It also implements a CreateWnd that creates a borderless window. The
meat of the class lives in the OnPaint handler, which does some basic geometry
calculations and then calls the MSJDrawTransparentBitmap helper function.
MSJDrawTransparentBitmap (see Figure 8) is a utility function that every Windows
programmer should have in their library. We found it long ago in KnowledgeBase.
It takes a bitmap and turns it into a mask so that it is transparently drawn
over the painting surface. A very handy function to have when you're
implementing panning.
Now that we have the cursor situation all straightened out, we need to add some
handlers to take care of starting, performing, and stopping the pan.
The first handler starts the pan when the user presses the IntelliMouse mouse
wheel, which generates a WM_MBUTTONDOWN message. Figure 9 shows the
implementation of our OnMButtonDown handler.
After verifying that the middle button is indeed down by checking the flags
passed, the OnMButtonDown handler captures the mouse and calculates where to
draw the origin window. Next, the handler stores the starting cursor position in
the m_ptMouseWheelOrg data member and sets m_bMouseWheelDrag to TRUE so that
other member functions know we are in a drag state. Then OnMButtonDown sets a
timer to fire every 10 milliseconds (good value for smooth panning). The ID of
the timer is stored in the m_nMouseWheelTimer data member. Finally,
OnMButtonDown creates, places, and shows an instance of our handy
MSJMouseWheelOriginWnd window that draws the origin bitmap at the position where
the cursor should be.
When the user moves the mouse with the mouse wheel depressed to pan, instead of
handling every mouse move message, we perform panning in the handler for the
timer: MSJSuperView::OnTimer. Figure 10 shows the OnTimer handler. It first
validates that it has received a timer with the same ID we set in OnMButtonDown
and that m_bMouseWheel Drag is set to TRUE. If this is the case, we are handling
an IntelliMouse pan, so OnTimer gets the current cursor position and calculates
an offset from the last cursor position stored in m_ptMouseWheelOrg. Once the
offset has been calculated, OnTimer uses this to calculate the direction and
amount of the pan. 
For example, if the user moved a short distance from the original position
cursor, then the panning is slow. If the user moved the mouse far away from the
original position, then the panning speeds up. This gives the user a variable
panning speed similar to that implemented in IE 4.0. After OnTimer calculates
the direction and amount of the scroll, it calls MSJSuperView::DoScroll to
actually pan the window, then it moves the MSJMouseWheelOriginWnd to the new
origin location so it doesn't get scrolled off the screen.
Panning stops when the user releases the mouse wheel; this is handled in the
MSJSuperView OnMButtonUp handler (see Figure 11). OnMButtonUp verifies that
panning is active by again checking m_bMouseWheelDrag, and then deletes the
MSJMouseWheelOriginWnd object. Next, it sets m_bMouseWheelDrag to FALSE,
indicating that the drag operation is over. Finally, OnMButtonUp releases the
mouse capture, kills the timer, and sets the cursor back to the original cursor
type and position. 


From the December 1997 issue of Microsoft Systems Journal. 
(http://www.microsoft.com/msj/1297/visualprog1297.aspx)

-Linda W. 


Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Actual Results:  
main mozilla window doesn't auto-scroll on Win platforms.



Expected Results:  
Conform to accessibility and UI compliance requirements regarding auto-scrolling
that were defined in 1997 in the Office 97 suite (and starting in IE4)

DO NOT mark this as a dup of 22775.  This is platform and accessibility
specific for the win32 platform (OSs Win98-> Winserver2003).

As someone with accessibility issues; (ulnar nerve, @C8 nerve bundle & cubital
tunnel), applying pressure to a mouse (clicks) is more painful than rolling
around a trackball that requires no finger motion. 

I wasn't sure if this belonged under accessiblity...but it seems to be a window
widget implementation.

For an initial solution, I'd suggest fixing it on the OS's that natively 
support it (win32) using the native invocation method (middle mouse click,
scroll-wheel click, or simulated middle-mouse click via simultaneous right and
left mouse clicks).  

I would suggest for compatibility, if over a link, behave as current (open new
window), else, activate scrolling function.  It's perfectly acceptable to have
different functionality based on whether over link or not: example, SELECT, over
link opens link in same window, over text, starts the beginning of a select text
operation.  Same idea....

Note, I removed the depends on 63712, since it is not reasonable to have to
first decide how to implement this on all OS's simply to provide equivalent
functionality that IE has had since V4 on Windows.  I don't like the
non-equivalency, but some OS's have more advanced toolkits/UI interfaces.  It
doesn't make sense to block native OS features on one platform because another
OS doesn't provide it.  You don't get to be best of breed on an OS by dumbing
down to the lowest common denominator of all OS's the product is supported on.

That's why I was tempted to label this as an Accessibility issue -- since there,
it's quite clear that the goal is to use the native accessibility features when
available -- not wait for the same accessibility features to become present on
all OS's.

If cross-OS politics become or continue to be a problem blocking this bug's fix,
I'll move it to Accessibility, since for me, and anyone with RSI's (Repetitive
Stress Injuries) or RSD's (...Disabilities), it is an accessibility issue.

I used to run native Linux desktop before my RSI's forced me over to Windows.
I still do development on Linux, but I use a windows laptop to log into the 
server or edit files over SMB (setup Linux box as Domain Master).

I chose Win98 as listed OS, since it is the lowest versioned OS that I know
supports this feature, but it's really for OS's up through Win2003 Server (there
doesn't seem to be a way to specify win32 as a platform nor choose multiple
OS's).


The following URL describes the behavior and contains sample C code to 
implement "autoscrolling":

http://www.microsoft.com/msj/1297/visualprog1297.aspx

IntelliMouse Panning

Panning is a really nice feature. You move around your document by holding down
the mouse wheel and moving the mouse to "pan" the document in the direction of
the mouse movement. In Microsoft Excel, panning lets you zip to the bottom-right
corner of your spreadsheet very quickly without ever having to click a scroll
bar. The speed of the pan is controlled by the distance of the cursor from where
you started panning. Try panning in Microsoft Excel or Word and you'll see what
we mean. 
As part of the IntelliMouse specification, Microsoft also defines a variety of
cursors to be used in IntelliMouse panning. For example, when a user clicks the
mouse wheel to initiate scrolling or moves the cursor back to the neutral zone
(the area around the panning origin), one of three standard cursors appears,
telling the user what level of panning support is provided.  

    ^
   <o> Indicates when two-dimensional panning is supported.  
    V

    ^
    o Indicates that vertical-only, one-dimensional panning is available.  
    V
 
 <-o-> Indicates that horizontal-only, one-dimensional panning is available 

During panning there are four cursors (eight if you support diagonal panning)
that show the direction of the panning:  
<o West   o> East  

 ^
 o North   o South 
           V
 
The panning support in many Microsoft IntelliMouse-compatible applications is
dramatically different. For example, Microsoft Excel and IE 4.0 implement
panning by creating the panning origin wherever the mouse happens to be (see
Figure 1). Word, on the other hand, implements only vertical panning and moves
the panning origin relative to the vertical scroll bar (see Figure 2). If you
plan on supporting only vertical scrolling, it may be a good idea to create a
CScrollBar derivative that handles the panning and scrolling so you can isolate
the support from your application. It seems like this is the approach taken by
the Word team. 
 
IntelliMouse AutoScroll 

In the IntelliMouse specification, an application should enter Autoscroll mode
when the user clicks the mouse wheel but doesn't drag it. 

>>>>> IE 4.0 has the smoothest implementation of this. It basically lets the
user start the windows scrolling and then continues to scroll until the user
moves the mouse or clicks another button. <<<<<

This is useful for applications like Word where the user may want to read large
volumes of vertical text, but does not want to scroll manually.
CScrollView meets only one requirement of the IntelliMouse specification葉hat
the view scrolls when the user moves the mouse wheel. This is largely because
CScrollView does not support zooming or panning. This month we will implement a
CScrollView derivative called MSJSuperView that supports zooming and panning
with the IntelliMouse. Before we can add IntelliMouse zooming and panning
support, however, we need to add zooming and panning support to the CScrollView. 
 

IntelliMouse Panning 

The tricky part about implementing IntelliMouse panning is the display of the
panning cursors. You have to display both the origin and directional cursors
while the user is panning. Since Windowsョ has only one cursor, this is pretty
daunting. To solve this problem, let's use the normal Windows cursor for the
directional panning and then create a special window to display the origin.
The origin window is called MSJMouseWheelOriginWnd (see Figure 7). It is
basically a very small CWnd derivative that implements some custom painting to
draw a transparent origin bitmap so that the bitmap can be seen through and
doesn't affect scrolling.
The MSJMouseWheelOrigin takes the resource ID for the bitmap to draw at the
origin. It also implements a CreateWnd that creates a borderless window. The
meat of the class lives in the OnPaint handler, which does some basic geometry
calculations and then calls the MSJDrawTransparentBitmap helper function.
MSJDrawTransparentBitmap (see Figure 8) is a utility function that every Windows
programmer should have in their library. We found it long ago in KnowledgeBase.
It takes a bitmap and turns it into a mask so that it is transparently drawn
over the painting surface. A very handy function to have when you're
implementing panning.
Now that we have the cursor situation all straightened out, we need to add some
handlers to take care of starting, performing, and stopping the pan.
The first handler starts the pan when the user presses the IntelliMouse mouse
wheel, which generates a WM_MBUTTONDOWN message. Figure 9 shows the
implementation of our OnMButtonDown handler.
After verifying that the middle button is indeed down by checking the flags
passed, the OnMButtonDown handler captures the mouse and calculates where to
draw the origin window. Next, the handler stores the starting cursor position in
the m_ptMouseWheelOrg data member and sets m_bMouseWheelDrag to TRUE so that
other member functions know we are in a drag state. Then OnMButtonDown sets a
timer to fire every 10 milliseconds (good value for smooth panning). The ID of
the timer is stored in the m_nMouseWheelTimer data member. Finally,
OnMButtonDown creates, places, and shows an instance of our handy
MSJMouseWheelOriginWnd window that draws the origin bitmap at the position where
the cursor should be.
When the user moves the mouse with the mouse wheel depressed to pan, instead of
handling every mouse move message, we perform panning in the handler for the
timer: MSJSuperView::OnTimer. Figure 10 shows the OnTimer handler. It first
validates that it has received a timer with the same ID we set in OnMButtonDown
and that m_bMouseWheel Drag is set to TRUE. If this is the case, we are handling
an IntelliMouse pan, so OnTimer gets the current cursor position and calculates
an offset from the last cursor position stored in m_ptMouseWheelOrg. Once the
offset has been calculated, OnTimer uses this to calculate the direction and
amount of the pan. 
For example, if the user moved a short distance from the original position
cursor, then the panning is slow. If the user moved the mouse far away from the
original position, then the panning speeds up. This gives the user a variable
panning speed similar to that implemented in IE 4.0. After OnTimer calculates
the direction and amount of the scroll, it calls MSJSuperView::DoScroll to
actually pan the window, then it moves the MSJMouseWheelOriginWnd to the new
origin location so it doesn't get scrolled off the screen.
Panning stops when the user releases the mouse wheel; this is handled in the
MSJSuperView OnMButtonUp handler (see Figure 11). OnMButtonUp verifies that
panning is active by again checking m_bMouseWheelDrag, and then deletes the
MSJMouseWheelOriginWnd object. Next, it sets m_bMouseWheelDrag to FALSE,
indicating that the drag operation is over. Finally, OnMButtonUp releases the
mouse capture, kills the timer, and sets the cursor back to the original cursor
type and position. 


From the December 1997 issue of Microsoft Systems Journal. 
(http://www.microsoft.com/msj/1297/visualprog1297.aspx)

-Linda W.
Alias: Autoscroll/win32
Blocks: majorbugs
Blocks: Autoscroll
Flags: blocking1.6a+
Flags: blocking1.5?
No longer blocks: majorbugs
Reporter, do not set a blocking flag to "+".  Only the drivers that decide what
bugs are blocker bugs have the authority to make that determination.

Taking 1.6a+ flag off.
Flags: blocking1.6a+
This is a dupe of bug 22775.

Mozilla doesn't have autoscrolling built in, but there's an extension that you
can use : http://autoscroll.mozdev.org/ . Mozilla has 'smoothscrolling', which
is only a visually better method of scrolling, and won't help you with your
problem. You can try it by setting 'general.smoothScroll' to true (in
about:config). The extension provides the same, but with the auto-scrolling that
you want (to avoid pressing the keys).

Note that Firebird seems to have switched to the extension-version, and so works
differently from the original Seamonkey browser. You might try that browser,
since it will the future Mozilla browser anyway.

*** This bug has been marked as a duplicate of 22775 ***
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
verified
No longer blocks: Autoscroll
Status: RESOLVED → VERIFIED
Flags: blocking1.5?
Product: Core → Mozilla Application Suite
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.