There was marked falloff in the twinopen results: http://graphs.mozilla.org/#spst=range&spstart=1202932291&spend=1204587974&bpst=cursor&bpstart=1202932291&bpend=1204587974&m1tid=148159&m1bl=0&m1avg=0&m2tid=199369&m2bl=0&m2avg=0 There was no change on branch to cause this change, and the other branch mac machine shows no similar change.
I found an open Bluetooth configuration dialog on the machine, I'll have to wait for the next cycle to see if that fixes the numbers.
I've seen that before. It's apparently a side-effect of having no keyboard or mouse attached to the computer.
The twinopen numbers have normalized now that the dialog has been closed. robcee - any idea how to make it so the dialog doesn't come back? Closing this bug.
This doesn't appear to have had anything to do with browser code at all. -> WORKSFORME
FIXED is the appropriate resolution for this bug, as an action was taken to fix the broken machine (in this case, closing a dialog). This component encompasses both testing code and QA machines. The two need to be split out into separate components, but until then, this is part of Core :: Testing.
Mass move of Core:Testing bugs to mozilla.org:ReleaseEngineering. Filter on RelEngMassMove to ignore.