Bugzilla – Full Text Bug Listing
| Summary: | Inconsistent horizontal scrolling behaviour (left/right) | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [RT] RAP | Reporter: | Jens Borrmann <jens.borrmann> | ||||
| Component: | RWT | Assignee: | Project Inbox <rap-inbox> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | ||||||
| Version: | 2.3 | ||||||
| Target Milestone: | 3.1 M1 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| Whiteboard: | sr301 | ||||||
| Attachments: |
|
||||||
Fixed in master with commit https://git.eclipse.org/r/#/c/52617/ |
Created attachment 255378 [details] Makes the behaviour observable with TableViewerTab of controls demo When navigating an editable table with the keyboard the horizontal scrolling behaviour depends on the direction that you are navigating: Left to right: when leaving the last entirely visible column (tab-key) scrolling makes the next column the leftmost column. The scrollbar "jumps" accordingly. Right to left: when leaving the last entirely visible column (reverse tab) scrolling moves the table just one column to the left. I could find good arguments for both algorithms, but is very surprising to users. I would opt for the "Right to left" way of scrolling. This is the way MS Excel works, which might be a good reference for table behaviour... I reproduced the bug with RAP controls demo (version 2.3.0) and attached a small patch that make the table in TableViewerTab wide enough to show the described behaviour. If accepted as a bug, we would need a fix not only for the latest version but also for version 2.3.1.