Community
Participate
Working Groups
Created attachment 111048 [details] Cannot scroll via KB in preference Build ID: I20080617-2000 Steps To Reproduce: 1. Set up the High Contrast mode for Windows OS, by selecting the High Contrast settings in Control Panel -> Accessibility Options -> Display 2. Launch Eclipse, and open the preference dialog 3. Navigate to General -> Appearance. You will find that, the right side content can not be displayed in one page, and a vertical scrollbar is shown up automatically. However, using keyboard only, you can not perform scrolling, thus you can not view the content hided in the bottom. 4. Navigate to Run/Debug -> Launching page, you will find that both veritical and horizontal scroll bar are shown up. But, with keyboard only, you can not perform any scrolling actions. More information:
Same underlying issue as https://bugs.eclipse.org/bugs/show_bug.cgi?id=245159 ?
(In reply to comment #1) > Same underlying issue as https://bugs.eclipse.org/bugs/show_bug.cgi?id=245159 ? > Similar, but not same. This bug#245366 is requesting to scroll via keyboard operatoins. And, bug#245159 is to scroll automatically to the current focus control.
Based on the current discussions on bug it appears that they are the same. PW
(In reply to comment #3) > Based on the current discussions on bug it appears that they are the same. Maybe this is really the more general solution. PW
Is there anything SWT could do for us, or do we have to solve this at the app level?
Perhaps something could be implemented in ScrolledComposite similar to org.eclipse.swt.widgets.Sash. The client would be responsible for calling API to activate the scrolling mode, but the work could be done in ScrolledComposite (or even more genernally, anything that takes a scroll bar). This would be in the nature of an enhancement, and the mode would have to be triggered programmatically. PW
Carolyn, this is the problem that I was talking to you about yesterday. Clients of ScrolledComposite expect to be able to scroll with the keyboard using arrows and page down when focus in not in a scrolled widget (ie. a table or list) or not in a widget that cares about the keys (ie. a single line text and a left or right arrow). This is a really old problem and I'm not sure that there is a general solution since it is not possible to know for sure which widgets like which keys (for example, a custom table widget would probably like up and down arrow). However, it might be possible to make some assumptions and catch most of the cases or give JFace code that can do this. Personally, I would lean towards a solution in ScrolledComposite. Duong to investigate and fix.
Can I get approx target?
I won't be able to look at this until January. Please ping me again then. Thanks.
(In reply to comment #9) > I won't be able to look at this until January. Please ping me again then. > Thanks. Ping..
This has a workaround in 3.4.2, bug 249527 that is not in 3.5 PW
Thank-you, Paul. So why didn't the work-around go into 3.5? Were you hoping for a more general solution in ScrolledComposite? I'm afraid we didn't get to this for 3.5, and we are pretty much frozen now.
(In reply to comment #12) > Thank-you, Paul. So why didn't the work-around go into 3.5? Were you hoping for > a more general solution in ScrolledComposite? Right, I agreed to put a workaround in 3.4.x and this was supposed to be addressed in 3.5 (the general problem that simply setting follow focus can leave the contents of a ScrolledComposite unviewable). PW
OK. I apologize - I should have set the target milestone. I'm setting it to 3.6 now.
Do we need the workaround in 3.5 then?
(In reply to comment #15) > Do we need the workaround in 3.5 then? I think we should consider the workaround for 3.5 then, since having it disappear already caused some confusion. See bug 274862 PW
Thank-you, Paul. The workaround is best at this point. If a generic solution needs to do some guessing as to widget behavior on all platforms (see comment 7), then it needs to go in early, like M1 or M2, so that any incorrect guesses are ironed out by the next M7...
Is this still targeted for 3.6?
No - sorry. We are completely swamped by some high priority tasks, and we cannot get to this. It is the kind of thing that needs to go in early in a release cycle. It will need to be re-prioritized in the next round.
Just for the record, the workaround for the Preferences dialog is still in effect - you can use the dialog local menu in the top right corner to get into keyboard scrolling mode.
Could you please tell me when this defect could be fixed without workaround? Thanks
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
