Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #347491 +++ We have several tests in JFace test suite that started intermittently fail after the recent Mac OS upgrade. The tests seems to fail on 10.6.7 using both 64 bit and 32 bit VM. The tests fail for both 3.6.2 and 3.7. The tests pass on 10.5.8. This means that there is likely change in behavior in Mac OS 10.6. The failing tests: SimpleVirtualLazyTreeViewerTest testCreation() assertTrue("call to updateElement expected", updateElementCallCount > 0); testRemoveAt() assertEquals(2, ((IStructuredSelection) treeViewer.getSelection()) .size()); AbstractTreeViewerTest testRefreshWithAddedChildren() assertNotNull("new child is visible", fViewer.testFindItem(child)); StructuredViewerTest testDeleteSibling() assertNotNull("first child is visible", fViewer.testFindItem(first)); testInsertSibling() assertNotNull("new sibling is visible", fViewer .testFindItem(newElement)); testInsertSiblings() assertNotNull("new siblings are visible", fViewer .testFindItem(newElements[i])); testSetInput() assertNotNull("first child is visible", fViewer .testFindItem(firstfirst)); testSomeChildrenChanged() assertNotNull("new sibling is visible", fViewer .testFindItem(newElement)); testWorldChanged() assertNotNull("new sibling is visible", fViewer .testFindItem(newElement)); http://download.eclipse.org/eclipse/downloads/drops/I20110526-1708/testresults/xml/org.eclipse.ui.tests_macosx.cocoa.x86_5.0.xml
Please see bug 347491 comment 6 and the associated change in the bug 347491 comment 8.
Ping. Any chance this could be looked into in M2?
Changing target milestone to 4.3. This should be looked at early in the cycle. SSQ, please have a look at FH's comments in bug 347491 comment 6 and bug 347491 comment 8.
What is the current status of these test failures with the latest versions of Eclipse and Mac OS? Are the failures still happening? Abhishek, can you check whether this is still a problem and continue the investigation if needed? Thanks!
(In reply to Arun Thondapu from comment #4) > What is the current status of these test failures with the latest versions > of Eclipse and Mac OS? Are the failures still happening? > > Abhishek, can you check whether this is still a problem and continue the > investigation if needed? Thanks! The tests are passing now. This bug can be resolved.
(In reply to Abhishek Kishore from comment #5) > The tests are passing now. This bug can be resolved. You should state here that you've removed the Cocoa exclusion in the tests (ViewerTestCase#disableTestsBug347491), and you should also state the OS version you used to verify.
(In reply to Abhishek Kishore from comment #5) > (In reply to Arun Thondapu from comment #4) > > What is the current status of these test failures with the latest versions > > of Eclipse and Mac OS? Are the failures still happening? > > > > Abhishek, can you check whether this is still a problem and continue the > > investigation if needed? Thanks! > > The tests are passing now. This bug can be resolved. Resolving the bug as 'WORKSFORME' as the test failures cannot be reproduced anymore. Please reopen in case the problem is seen again.
Comment 6 has not been answered. It's no wonder that disabled tests don't fail. There are still problems with virtual trees on the Mac (e.g. bug 429584), and the JFace tests in org.eclipse.ui.tests could help identify those problems.
(In reply to Markus Keller from comment #8) > Comment 6 has not been answered. It's no wonder that disabled tests don't > fail. > > There are still problems with virtual trees on the Mac (e.g. bug 429584), > and the JFace tests in org.eclipse.ui.tests could help identify those > problems. Sorry my bad, I assumed the tests were enabled and are passing now. Abhishek, can you please take a re-look at the disabled JFace tests?
(In reply to Arun Thondapu from comment #9) > Abhishek, can you please take a re-look at the disabled JFace tests? I'm explicitly running the test cases mentioned in the bug. All of them are passing for me. I'm testing with Luna RC4 on OSX 10.9.3. I'll test on OSX 10.6.x as well, see if it happens.
The tests pass in I20140606-1215 on Mac OS X 10.9.3 because bug 118919 effectively disabled them. On the Mac, SetData always seems to be late. But it's hard to identify the real cause, since SWT still doesn't have an API for SetData, see bug 81334. If SetData can be delayed even if Display#readAndDispatch() returned false, then the API should specify that, and tests should be updated to conform to the API (e.g. by waiting with a timeout).
Bug 347491 comment 6 has the interesting analysis of this bug: > For me, the simple answer is that readAndDispatch() is returning false when > it should be returning true. > Internally to SWT, application.nextEventMatchingMask() is returning null > (which indicates that the event queue is empty, thus the application can go > to sleep). But, application.nextEventMatchingMask() is causing work to > happen, selectors are running, even SWT paint events get dispatched. > > In this case, the first call to readAndDispatch() (which IMO is wrongly > returning false), is in fact causing several selectors to run, including: > sel_setNeedsDisplay_ and sel_setNeedsDisplayInRect_ on the scrollbars, and > sel_updateTrackingAreas on the tree and shell.
I see similar set of tests failing on Ubuntu 14.10. https://bugs.eclipse.org/bugs/show_bug.cgi?id=457464#c2
We will investigate this post 4.5.
We need verify this on OSX 10.11. We'll not be able to investigate this for 4.6. Deferring for now.
(In reply to Lakshmi Shanmugam from comment #15) > We need verify this on OSX 10.11. We'll not be able to investigate this for > 4.6. Deferring for now. I enabled the tests by setting ViewerTestCase.disableTestsBug347491 = false and ran them on macOS 10.12. I get these failures: org.eclipse.jface.tests.viewers.SimpleVirtualLazyTreeViewerTest testRemoveAt org.eclipse.jface.tests.viewers.VirtualLazyTreeViewerTest testSomeChildrenChanged testInsertSibling testWorldChanged testInsertSiblings testSetInput Deferring to 4.8.
Moving to 4.9, please re-target as required.
Resetting target.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
