Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 325465

Summary: Virtual viewer tests timeout when viewer is hidden
Product: [Eclipse Project] Platform Reporter: Darin Wright <darin.eclipse>
Component: DebugAssignee: Pawel Piech <pawel.1.piech>
Status: CLOSED WONTFIX QA Contact:
Severity: normal    
Priority: P3 CC: daniel_megert, kim.moir, Michael_Rennie, pawel.1.piech, sarika.sinha
Version: 3.7   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
Whiteboard: stalebug
Bug Depends on:    
Bug Blocks: 412552    

Description Darin Wright CLA 2010-09-16 09:38:28 EDT
The virtual viewer tests have been failing on linux due to an update service dialog being open on the machine when the tests run. If possible, we should force the viewer shell to be on top/in the foreground.
Comment 1 Pawel Piech CLA 2011-02-16 17:57:07 EST
I converted the shells used in the viewer to use SWT.ON_TOP.  The down-side is that on Linux/GTK, this removes the shell's trim controls, but the tests still work.

Mike, please have a look.
Comment 2 Pawel Piech CLA 2011-02-17 14:26:42 EST
It seems that changing the shell style to ON_TOP had a bad effect on the Linux tests.  I'm going to make a slight adjustment: instead of calling shell.setMaximized(), i'll call shell.setSize(800,600).  We'll see if this has a positive effect on the over night tests.

The Mac tests also ended in DNF.  I'll run those locally.
Comment 3 Pawel Piech CLA 2011-02-17 14:27:13 EST
I'll leave the bug open until the nightly tests pass.
Comment 4 Pawel Piech CLA 2011-02-18 14:08:39 EST
The tests on Linux passed last night so that's some progress.  However, I'm seeing something very odd on Mac.  
I managed to get my home Mac (10.6 x86_64) set up to run the tests and I get a behavior where the tests repeatedly get stuck with no updates in the viewers. If I manually change the focus away from the shell with the viewer, the viewer refreshes and the test continues.  It's as if the lazy loading viewer thinks that it's covered by another window and simply doesn't refresh.  I found 
bug 307322 but it doesn't explain why the nightly tests end in DNF when they were running fine in M5 on the same hardware.
Comment 5 Pawel Piech CLA 2011-02-18 14:29:32 EST
My theory about finding a duplicate of bug 307322 didn't pan out because I cannot reproduce that failure on my Mac.  I'll try reverting the new shell behavior (SWT.ON_TOP) for macs and see if that cures the DNF in nightly build.
Comment 6 Pawel Piech CLA 2011-02-22 12:46:36 EST
The mac tests started passing again as so did others.  So I'm marking as fixed.  Although the win32 tests ended with a dnf on the 21st so if a popup window was responsible then the ON_TOP style didn't help there.  

I'm closing this bug for now.  If we get persistent failures we may need to consider some other alternatives for these tests.
Comment 7 Michael Rennie CLA 2011-02-24 12:16:09 EST
I think we need to revisit the tests, the Win test DNF'd again in the N20110222-2000 build
Comment 8 Pawel Piech CLA 2011-02-25 13:36:29 EST
I still can't reproduce the DNF locally, so I'm kind of shooting in the dark:

I tried one theory last night - by disabling a test that was recently changed, but that didn't help.  Now I backed out the change made originally for this fix for the Windows platform (I already backed it out for Mac).  Let's see if that cures it.
Comment 9 Pawel Piech CLA 2011-02-28 13:02:47 EST
(In reply to comment #8)
The tests still ended with DNF over the weekend.  I'm out of ideas on this since I can't reproduce the failure locally.  Mike do you know if there is any way we could "see" the tests failing on the test machine.
Comment 10 Michael Rennie CLA 2011-02-28 14:47:46 EST
(In reply to comment #9)
> (In reply to comment #8)
> The tests still ended with DNF over the weekend.  I'm out of ideas on this
> since I can't reproduce the failure locally.  Mike do you know if there is any
> way we could "see" the tests failing on the test machine.

There is no way that I am aware of, the person to ask would be Kim.

CC'ing Kim for comment.
Comment 11 Kim Moir CLA 2011-02-28 14:59:21 EST
We are having problems with the Windows machine being logged off as the build user intermittently which can cause these types of tests.  I'm working right now with the sysadmin to try to solve this.  It's impacting other teams.  Very frustrating.
Comment 12 Pawel Piech CLA 2011-02-28 16:01:55 EST
Thank you Kim for the clarification.  I wish I asked sooner :-)
Comment 13 Pawel Piech CLA 2011-03-02 11:08:34 EST
The tests are passing again, and the changes from this bug are mostly disabled.  All in all, I think I'm starting to think that the ON_TOP style is not really buying us any advantage.  For example it didn't help any on the Windows machine that was logging out the user.  Any opinions?
Comment 14 Michael Rennie CLA 2011-03-02 11:27:02 EST
(In reply to comment #13)
> The tests are passing again, and the changes from this bug are mostly disabled.
>  All in all, I think I'm starting to think that the ON_TOP style is not really
> buying us any advantage.  

I agree, I don't think there is much we can do, if even forcing the viewer to be ON_TOP does not prevent the tests failing.
Comment 15 Pawel Piech CLA 2011-03-02 14:03:02 EST
I backed out the ON_TOP change.
Comment 16 Michael Rennie CLA 2013-08-06 12:17:28 EDT
We still get DNF failures. Had another failure on I20130730-0800.

Could we not run the tests inside a 'normal' workbench? How come we have to have the viewer so large / on top / etc?
Comment 17 Michael Rennie CLA 2013-08-06 12:17:40 EDT
*** Bug 414097 has been marked as a duplicate of this bug. ***
Comment 20 Lars Vogel CLA 2019-11-27 07:19:44 EST
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.

If you have further information on the current state of the bug, please add it.
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.

If the bug is still relevant, please remove the stalebug whiteboard tag.