Bugzilla – Full Text Bug Listing
| Summary: | [Intro] Mouse click in scroll bar scrolls one line | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Knut Radloff <knut_radloff> |
| Component: | User Assistance | Assignee: | platform-ua-inbox <platform-ua-inbox> |
| Status: | RESOLVED WORKSFORME | QA Contact: | |
| Severity: | normal | ||
| Priority: | P4 | ||
| Version: | 2.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| Whiteboard: | |||
|
Description
Knut Radloff
A question on behaviour. As the welcome page is made up of multiple styled text widgets what behaviour should be exhibited when the page up/page down scroll distance does not land in one of the text widgets? That is, what if the action were to cause the cursor to attempt to position in the white space between widgets? I am currently thinking to position it in the next/previous widget, but then the distance scrolled is greater/less than one page. Suggestions, comments? What you are talking about should only be an issue when the Page Up and Page Down keys are pressed, not when you click above/below the scroll thumb in the scroll bar. For this case, the caret should not move. Agree with Lynne about mouse initiated scroll. As for keyboard scroll the caret should probably be in the last visible widget on the page after the scroll if you scroll down or in the topmost visible widget when you scroll up. The question is, why do we have a caret in the first place? You can't edit text and I doubt that selecting text in a welcome editor is particularly useful. Also, you could still select text using the mouse. I think the best solution would be to get rid of the caret and simply page scroll. If we think we need a caret you also have to handle the case were no text widget is visible after a page scroll. In that case the caret should probably go in the widget that is nearest the bottom/top edge for page down/up respectively. I am also in agreement with Lynne. I am still thinking about the case of page up/down and whether I should keep the caret or not. The welcome editor is as you know read only. That being said the ability to copy the text elsewhere is supported, as requested by a different PR. Thus I believe we must keep the caret. If I page up/down and I don't move the caret, then a subsequent tab would cause the editor to flash back to where it last was. This is contrary to the behaviour exhibited by the current java editors. Summary: I will not move the caret on mouse initiated scrolls. For single line keyboard scrolls I will just jump to the appropriate widget when required. For page up/down keyboard scrolls I will do the behavior as described by Knut. *** Bug 27545 has been marked as a duplicate of this bug. *** Defer I ran across this behavior recently and was surprised to see it had been reported a long time ago but was still open. Clicking above or below the thumb in a scroll bar normally flips a full screen. Although there may be implementation reasons why this isn't what happens in the welcome screen, it is surprising to a user who expects scroll bars to work in the usual way. Seems to work fine for me in 3.2. Closing. |