Closed Bug 761075 Opened 12 years ago Closed 12 years ago

Investigate why only talos-r3-w7-026 has the mouse where it causes reftests/bugs/424766-1.html to fail

Categories

(Infrastructure & Operations Graveyard :: CIDuty, task)

Product:
Infrastructure & Operations Graveyard
Component:
CIDuty
Platform:
x86
Windows 7
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: philor, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: intermittent-failure, Whiteboard: [buildduty]) 

http://mxr.mozilla.org/mozilla-central/source/layout/reftests/bugs/424766-1.html?force=1 has a button in it which seems sort of unnecessary, but that's not the point.

Bug 755955 points out that the reftest harness doesn't take care of making sure that both the test and the reference are in the same hover state when the snapshots are taken, but that's not the point.

The point is that at least since last Thursday, while no other Win7 slave has the mouse where the button is hovered, talos-r3-w7-026 has it where every single time it is hovered (but only randomly showing a hovered button, and thus failing the test since it's not both the test and the reference hovered).

My three theories were:

it's running a different resolution than every other one, or Win7 preserves mouse position across reboots, or it hasn't rebooted for days

but after

<bear-afk>: I just rebooted it - it hadn't been touched in a while

it still fails - https://tbpl.mozilla.org/php/getParsedLog.php?id=12345487&tree=Mozilla-Inbound

Is it running with the wrong resolution, so that when it reboots and Windows sticks the cursor in the middle of the screen, it's in a different place on that slave than it is on every other slave? Is, um, the window opening in a different place than it does on other slaves? Surely it isn't that Win7 actually does preserve mouse position across reboots, is it?
I really don't know how to determine why.
Perhaps someone VNCed into it and place the mouse in an undetermined position (even though I saw it at the center of the screen).

BTW I have moved the mouse to the right upper corner and hopefully we won't hit any more issues with this specific slave.


FTR I might be adding a step in bug 712630 to fix the mouse in a certain position of the screen so all win7 slaves will be in a closer state. At least, that is what I wish for.
The slave has been disabled in slavealloc.
Philor, we added a script that moves the cursor away to the top right corner.
I would like to add this machine back to the pool.

Sounds good?
Whiteboard: [orange] → [orange][buildduty]
Sure, it's easy enough to recognize if it goes astray.
This machine has been generally green for awhile now, I think this is fixed?
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Whiteboard: [orange][buildduty] → [buildduty]
Product: mozilla.org → Release Engineering
Product: Release Engineering → Infrastructure & Operations
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in before you can comment on or make changes to this bug.