Bug 295666 - [JFace] 1 failure in org.eclipse.jface.tests @ ListViewerTest
Summary: [JFace] 1 failure in org.eclipse.jface.tests @ ListViewerTest
Status: CLOSED DUPLICATE of bug 74739
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 3.5.1   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Platform-SWT-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 295103
  Show dependency tree
 
Reported: 2009-11-19 20:11 EST by Roland Grunberg CLA
Modified: 2010-02-11 10:53 EST (History)
6 users (show)

See Also:


Attachments
SWT Test snippet (1.34 KB, text/x-java)
2009-11-24 07:52 EST, Praveen CLA
no flags Details
Isolated test method for problem cause on GTK (1.31 KB, patch)
2009-12-08 10:27 EST, Ralf Ebert CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Roland Grunberg CLA 2009-11-19 20:11:33 EST
ShowSelection() call in (ListViewerTest:101) seems to be changing the top 
index of the viewer even though the selected item seems to be visible on the 
screen. This could happen because ShowSelection() may scroll the selected item
to the top of the screen even if it is already visible. However, the actual
showSelection() method from the List class of org.eclipse.swt.widgets seems to
enter an if() statement that implies the item is not visible on the screen.

[tester@localhost eclipse-build]$ rpm -q gtk2
gtk2-2.18.3-21.fc12.i686


Steps To Reproduce and Fix

-- Grab Eclipse 3.5.1 for Linux-Gtk, install it, and run it.

-- Within Eclipse, switch to the CVS perspective and add the following
   repository :

:pserver:anonymous@dev.eclipse.org/cvsroot/eclipse

-- Within the repository Click on 'Versions' and check out the following :

-- Check out 'org.eclipse.ui.tests M20090812-0800a' under 'org.eclipse.ui.tests'

This will depend on the following, so check them out as well.

-- Check out 'org.eclipse.core.tests.harness v20090525' under 'org.eclipse.core.tests.harness'
-- Check out 'org.eclipse.test.performance v20090511 ' under 'org.eclipse.test.performance'
-- Check out 'org.eclipse.ui.tests.harness I20090525-2000' under 'org.eclipe.ui.tests.harness'

All the version numbers are chosen based on :

http://download.eclipse.org/eclipse/downloads/drops/R-3.5.1-200909170800/directory.txt

-- Now open the file 'ListViewerTest.java' (ctrl+R)

-- Run the file as a j-unit plugin test to confirm that testRevealBug69076
   is the only failing testcase. You could also run the full test suite at
   org.eclipse.ui.tests/Eclipse JFace Tests/org.eclipse.jface.viewers/AllTests.java

-- On line 86, replace '40' with '15' and replace '45' with '20'

-- On line 90, replace '30' with '10'

-- Run the file again as a j-unit plugin test to confirm that all test cases
   pass
Comment 1 Hitesh CLA 2009-11-23 04:20:06 EST
Not reproducible on windows.I could reproduce this on my linux box.

Moving to SWT for comment.

Seems like the widget is not yet ready (pending events), when it comes to fViewer.reveal(child) call in the inner 'for' loop.
Comment 2 Praveen CLA 2009-11-24 07:52:27 EST
Created attachment 152940 [details]
SWT Test snippet

The problem is boiled down to a simple SWT snippet. 
It seems that the events are not processed properly as the list items are added after the shell is opened and before the main event loop.
Comment 3 Praveen CLA 2009-12-08 04:21:33 EST
I just realized that this is a duplicate of bug#74739
Comment 4 Andrew Overholt CLA 2009-12-08 09:04:52 EST
How do the JFace tests achieve 100% during the Eclipse SDK builds?
Comment 5 Ralf Ebert CLA 2009-12-08 09:19:55 EST
This is dependant on the font size. I assumed on windows the font is small enough by default not to scroll (could somebody check?). I also assumed that the font on the linux test boxes might be small enough though (any way to verify this wild guess?). For me this fails on Ubuntu 9.10, GTK 2.18.3. I think the correct way to fix this is to set the shell height to 45*lineHeight + windowBorderHeight. I just couldn't figure out how to get the windowBorderHeight :)
Comment 6 Ralf Ebert CLA 2009-12-08 10:27:57 EST
Created attachment 154012 [details]
Isolated test method for problem cause on GTK

I was wrong about the font sizes. I isolated the cause on GTK 2.18 into a separate test case, patch attached. You can work around this problem by calling processEvents() after setSelection() in the test method, but this should not be necessary.
Comment 7 Ralf Ebert CLA 2009-12-08 10:47:29 EST
This depends on bug 92176 - if you do the processEvents after setInput as workaround on GTK, both test methods are working as expected
Comment 8 Praveen CLA 2010-02-11 10:53:36 EST
Closing this as the duplicate of bug#74739. Please re-open if JFace team need to have this bug open to track dependant bugs.

*** This bug has been marked as a duplicate of bug 74739 ***