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)
Tracking
(Not tracked)
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.
Blocks: Autoscroll
Comment 1•21 years ago
|
||
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+
Comment 2•21 years ago
|
||
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
Comment 3•21 years ago
|
||
verified
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
You need to log in
before you can comment on or make changes to this bug.
Description
•