561052 - TEST-UNEXPECTED-FAIL | test_buttons_collapse_and_expand | EXCEPTION: The collapsy bar should not be shrunk!

Status: RESOLVED FIXED

(Thunderbird :: Search, defect)

Description

[Mark Banner (:standard8)]

Seen on the 1.9.2 and trunk Windows test boxes after landing of bug 545955:

TEST-UNEXPECTED-FAIL |  test_buttons_collapse_and_expand
  EXCEPTION: The collapsy bar should not be shrunk!
    at: test-display-issues.js line 91
       Error("The collapsy bar should not be shrunk!")  0
       assertExpanded() test-display-issues.js 91
       test_buttons_collapse_and_expand() test-display-issues.js 100

This seems to be a permanent failure.

Also seen on the 1.9.2 branch Linux unit test boxes on Thunderbird test. Doesn't seem to appear on trunk for the Linux boxes, but that could be due to other failures on those boxes.

Comment 1

[Andrew Sutherland [:asuth] (he/him)]

The working assumption is that the failures are happening on boxes with screen resolutions in the neighborhood of 1024 wide, and we need something more like 1200.  My workaround is to collapse the folder bar for the test.

I pushed a bustage-fix for this, although I mis-allocated it to bug 545955:
http://hg.mozilla.org/comm-central/rev/d7fdba3f04e3
http://hg.mozilla.org/comm-central/rev/b4b8c96d6dbd

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

Those patches did not fix the problem.  The reference platform docs suggest the windows machine should be running at 1280x1024, but I'm unclear if that is actually happening per a comment from Standard8 that he was unable to change it.

Reference stuff: https://wiki.mozilla.org/ReferencePlatforms/Win32

I probably should have added some additional debug to figure out what is happening... that would likely be the next step.

Comment 3

[Andrew Sutherland [:asuth] (he/him)]

I pushed a bustage fix that causes the splitters to actually collapse and adds additional debugging in case the problem is not what I thought it is:
http://hg.mozilla.org/comm-central/rev/2974e8b4fb57

Comment 4

[Andrew Sutherland [:asuth] (he/him)]

It would appear that fixed it.  Marking this fixed and raising the issue of the standard resolution of our builders on tb-planning.

I'm going to leave the dump debugging in for now.

Comment 5

[Andrew Sutherland [:asuth] (he/him)]

this is being intermittent orangey now...
http://tinderbox.mozilla.org/showlog.cgi?log=Thunderbird3.1/1272190247.1272199197.10213.gz

gozer, can you respond to my message in tb-planning asking what the state of the resolution of the given tinderbox is?  (I asked there since the answer is likely useful to others too)

I'm flying blind without stdout and any other information...

Comment 6

[Philippe M. Chiasson (:gozer)]

momo-vm-\d+ VMs have been reconfigured to the correct resolution

Comment 7

[Andrew Sutherland [:asuth] (he/him)]

danke!  I'll keep an eye on the tinderbox; hopefully someone had just connected with a very very tiny window recently.

Comment 8

[Phil Ringnalda (:philor)]

http://tinderbox.mozilla.org/showlog.cgi?log=Thunderbird3.1/1273434189.1273437581.21598.gz

Comment 9

[Phil Ringnalda (:philor)]

http://tinderbox.mozilla.org/showlog.cgi?log=Thunderbird/1273438194.1273442200.1192.gz

Comment 10

[Dan Mosedale (:dmose, :dmosedale)]

This seems to have gone from intermittent orange to full-time orange, which has me concerned about it masking other failures later in the test run.  What's the next step here?

Comment 11

[Mark Banner (:standard8)]

We've disabled the test for now:

http://hg.mozilla.org/releases/comm-1.9.2/rev/c3f50b44d819
http://hg.mozilla.org/comm-central/rev/062ee8c17db3

Comment 12

[Mark Banner (:standard8)]

Update: It appears our method of RDPing into the windows boxes was changing the resolution they were running at.

gozer is fixing them today so we should be safe to try re-enabling in the next few days, though I'd like to look and see if we can get a screen resolution report into at least the test as well as re-enabling it.

Comment 13

[Andrew Sutherland [:asuth] (he/him)]

I thought he had already fixed that?  Or was that just VMware?

The test dumps resolution data on stdout, but that doesn't show up in the output log; presumably the tinderbox is not listening to that stream or the mozrunner is one of the older releases that decided to drop it on the floor.  Certainly you can move/copy it so it puts that in the exception dump too.

Now that I think gozer has a friend maybe we can get the couchdb setup so we can do the richer logging too?

Comment 14

[Mark Banner (:standard8)]

(In reply to comment #13)
> I thought he had already fixed that?  Or was that just VMware?

It was an issue with the RDC clients that we were using - as we logged into the clients the way they were operating meant the display resolutions got re-adjusted to something smaller.

Now gozer & I have fixed our clients, I've checked in a couple of changes to re-enable test_buttons_collapse_and_expand:

http://hg.mozilla.org/comm-central/rev/eb6e07797656
http://hg.mozilla.org/releases/comm-1.9.2/rev/ca180a6c356a

The trunk ones have been holding up fine, so should the branch ones.
 
> The test dumps resolution data on stdout, but that doesn't show up in the
> output log; presumably the tinderbox is not listening to that stream or the
> mozrunner is one of the older releases that decided to drop it on the floor. 
> Certainly you can move/copy it so it puts that in the exception dump too.

I've filed bug 568457 as a follow-up to sort out what we do if the display resolution is wrong.

> Now that I think gozer has a friend maybe we can get the couchdb setup so we
> can do the richer logging too?

That's quite possible.