| Summary: | Scrollpanel keeps scrolling to top | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Jamie Strachan <frostfreek> |
| Component: | SWT | Assignee: | Platform-SWT-Inbox <platform-swt-inbox> |
| Status: | RESOLVED WORKSFORME | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | bsd, ericwill, ezelspinguin, frostfreek, h.klene, mail, martin.fleurke, pwebster, stephan.herrmann, tparker |
| Version: | 4.3 | Keywords: | triaged |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux-GTK | ||
| Whiteboard: | |||
|
Description
Jamie Strachan
Oops, in situation A above, I meant: 3. Using the mouse, scroll down to the middle of the list I've seen this too on Linux/GTK: it happens with the CSS Spy too. It appears to be related to tables with column editors. I haven't been able to trace it further to see if it's a problem with JFace or SWT's editing support. Also happens with the Window list (Ctrl-E) when there are a lot of entries. This bug report so far doesn't make it clear just how blocking this bug is for a normal workflow. The OP also hints that using the mouse is a valid workaround, but it's rather the other way around. I'm experiencing this too since 4.2: Version: 4.2.1 Build id: M20120914-1800 Mint Linux 14 I'm using the Cinnamon desktop. C. As Brian said, this occurs with the Window List (Ctrl-E). When coding, frequently, you want to bring a hidden file editor to the front, but this common behavior that should be quick is now very much slowed down. 1. Have many .java files open in the editor (>99). 2. Click the overflow button (or Ctrl-E) to open the full list. The scrollbar is at the top. 3. Use mousewheel scrolling and scroll more than a few 'pages' down (to the second half or so). So far so good. 4. Notice how the selector doesn't follow along, until you move your mouse pointer. The row it's hovering above gets selected but instantaneously the selection and page view jumps back to almost the beginning (maybe the second page or so). This jumping-back is unexpected and makes it hard to select files beyond the second page. 5. Notice that as you move your mouse pointer closer to the top of your screen, the list scrolls back further, making it even more impossible to hit your target. Similar experience when scrolling with the mouse by using the scrollbar. The workaround is to open the list, not touch the mouse, and navigate with the cursor keys. Or to type in the first letters of the file you're searching for (which may be hard because the first letters are often the same). A. For me the only workaround is to use the keyboard. Mouse scrollbar dragging or mousewheel scrolling are too obstructed. B. For me this is only apparent if you scroll far enough down, and the screen starts flashing. And I forgot what is likely the worst: I see this in the Java editor too. When I click an element in the Outline, which is well down, the editor opens but not at the location of the element. Or it opens, puts the element nicely at the top of the window, but then the scrollbar shows there is no code above it. If you scroll down a bit inside the editor, suddenly you jump to a different position in the editor and the scrollbar lets you reach all parts again. Since this involves scrolling, I'm assuming it is related. *** Bug 395343 has been marked as a duplicate of this bug. *** I can reproduce this problem on LinuxMint14(32bit) with Eclipse 4.2.1 M20120914-1800(Juno SR1/Latest Release) but cannot with Eclipse 4.2.1 M20121128-1200(4.2 Maintenance Build) I believe it was fixed already. *** Bug 388768 has been marked as a duplicate of this bug. *** *** Bug 370079 has been marked as a duplicate of this bug. *** *** Bug 376474 has been marked as a duplicate of this bug. *** For the records: in bug 370079 I had narrowed down some of the Ctrl-E weirdness to having been introduced somewhere between 3.8M3 and 3.8M4. FWIW: I don't see this in 4.3M5 I retried all regressions from duplicate bug 370079 and also here: all looks good (I used I20130108-0800). It would for sure be comforting to know which fix fixed the problems (after the breakage has been narrowed down to between 3.8M3 and 3.8M4), but other than that I wouldn't mind if this bug is closed as is. Now that I tried to reproduce it, this scrolling bug also vanished for me. Eclipse 4.3M3 I20121031-2000 Oracle jdk1.7.0_09 I had not much time recently to play with current milestones of eclipse or even updating my jdk on this machine. Instead I got an update to Kubuntu 12.10 Quantal Quetzal meanwhile. So I suggest, this was not really an SWT/Java issue but rather a bug in the underlying native GUI components? (In reply to Holger Klene from comment #14) > Now that I tried to reproduce it, this scrolling bug also vanished for me. > > Eclipse 4.3M3 I20121031-2000 > Oracle jdk1.7.0_09 > > I had not much time recently to play with current milestones of eclipse or > even updating my jdk on this machine. Instead I got an update to Kubuntu > 12.10 Quantal Quetzal meanwhile. So I suggest, this was not really an > SWT/Java issue but rather a bug in the underlying native GUI components? I have not seen this in the 4.4 release. Is anyone going to be able to do the analysis to determine how it was fixed, or should the bug just be marked as closed? (In reply to Terry Parker from comment #15) > I have not seen this in the 4.4 release. Is anyone going to be able to do > the analysis to determine how it was fixed, or should the bug just be marked > as closed? Let's close it. |