Community
Participate
Working Groups
Build Identifier: 20100917-0705 Attributes combo boxes with a long list of entries, such as "Target milestone" or "Version", scroll up when the user clicks on an entry that is above the bottom visible entry in the list, making proper selection nearly impossible. When I drop these combo boxes down, I can see roughly 9.4 lines. If I click on any but the bottom visible line, the selection scrolls up and closes the combo box without my targeted selection. This is most visible with a very long list of entries. When I scroll to the bottom of the list, then attempt to make a selection somewhere in the middle of the visible entries, if I hold my mouse button down rather than performing a momentary click, I can see that the highlighted selection that is picked up by the UI is the last visible one in the list. The UI apparently thinks that I have selected the last one, and while holding down the mouse button, moved the cursor up, indicating I want to scroll up, which it does. Intended behavior should be to select the line the cursor was hovering over when the click was received, then closing the combo box without any scroll. The main issue here, I think, is that the combo box is always seeing the bottom visible item as selected when a click is detected. I know this bug report is sort-of strange, and I'm finding I have a difficult time describing it, so I would be happy to provide a video if the behavior if that would help. I have found no workaround for this bug and am having a very difficult time making selections in task attributes because of this. Reproducible: Always Steps to Reproduce: 1. Open a task, in my case a Bugzilla task, and expand the Attributes section. 2. Open a combo box in the attributes section that contains a long list of entries. 3. Scroll to the bottom of that combo box's list of entries. 4. Choose a list entry somewhere in the middle of the visible list of entries and click on it. 5. See that the entry you chose is not what the combo box is displaying upon close. 6. Repeat steps 2 and 3. 7. Choose a list entry somewhere in the middle of the visible list of entries and click and hold on it. 8. See that the combo box has the last visible list item selected and is scrolling up at a rapid rate.
I don't see this problem on Gtk. Leo, Rob, can you reproduce this?
Yes, pretty easily reproducible on Mac. Sounds like a platform bug?
(In reply to comment #2) > Yes, pretty easily reproducible on Mac. Sounds like a platform bug? Probably so. I think it was recently introduced as well. I hadn't experienced this issue with Eclipse Galileo releases or any of the Eclipse Helios release candidates. It didn't show up for me until the final release of Eclipse Helios, which I have had on my system prior to Apple's recent Java update (update 3).
Thanks. Moving to platform.
Is this on Carbon or Cocoa? If Carbon we won't be addressing it for 3.7. Otherwise I'll have a look.
(In reply to comment #5) > Is this on Carbon or Cocoa? If Carbon we won't be addressing it for 3.7. > Otherwise I'll have a look. This is in Cocoa.
Okay, I'll see what I can do for 3.7.
The problem is that CCombo is calling List#setSelection in the middle of handling a Selection event on the list. setSelection is scrolling the list so the selection is at the bottom, and it just keeps repeating itself over and over. This is because we're sending selection events during tableViewSelectionIsChanging -- the mouse tracking isn't finished yet, but we're calling selectRowIndexes:. This will be tough to fix, since we like the behavior of firing selection events as the list, table or tree updates.
It's more complicated than I thought. Mylyn is completely destroying and regenerating the list every time we send a selection event. This resets the scroll position every time back to the origin. Calling select() then shows the selected item, but because the scroll position was changed, scrollRowToVisible just puts the selected item at the bottom of the visible portion of the list. And since the mouse is still in a tracking loop, the selected item changes to the item under the mouse, which sends another selection event, and the cycle repeats.
Fixed > 20110106. List/tree/table selection now behaves more like the Mac, and events still arrive in the proper order. (mouseDown/Selection/mouseUp).
With these changes, the SWT.Selection event only comes when the mouse button is released which is wrong since the item is selected on mouse down. This a bug on the windows List as well, but not in the windows Tree/Table. Also, SWT.Selection does not come if you press and hold the mouse button and drag select.
(In reply to comment #11) > With these changes, the SWT.Selection event only comes when the mouse button is > released which is wrong since the item is selected on mouse down. This a bug on > the windows List as well, but not in the windows Tree/Table. > > Also, SWT.Selection does not come if you press and hold the mouse button and > drag select. The item is not selected on mouse down. Visually it appears to be, but on Mac OS X the selection occurs on mouse release -- that's why there's a selectionIsChanging and selectionChanged. With the current design of CCombo, it's impossible to allow drag selection, because the list is being destroyed and rebuilt with every Selection event. You can't change the contents of the popup. I don't see how that can work on any platform, let alone Cocoa.
(In reply to comment #12) > With the current design of CCombo, it's impossible to allow drag selection, > because the list is being destroyed and rebuilt with every Selection event. You > can't change the contents of the popup. I don't see how that can work on any > platform, let alone Cocoa. Ignore this rant. :-) I just figured out how to fix it. The problem is calling noteNumberOfRowsChanged while in the middle of the tracking loop. scrollRowToVisible shouldn't change the scroll position if the row is already visible, but that only works if the visible rect is correct.
Applied a better fix. If the mouse is down, don't call noteNumberOfRowsChanged, as this will change the selection and the scroll position. Also undid the changes to Tree, as add/remove doesn't have the same meaning. We may have to revisit this for Tree at some point, but until then no need to change the code to allow for it.
*** Bug 309465 has been marked as a duplicate of this bug. ***
