Closed Bug 641193 Opened 13 years ago Closed 13 years ago

improve fancy mozmill logging, round 2

Categories

(Thunderbird :: Testing Infrastructure, defect)

x86_64
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 5.0b1

People

(Reporter: asuth, Assigned: asuth)

Details

Attachments

(1 file)

Here are some logging improvements I would like to land because they will help me fight our fairly consistent intermittent oranges.  I was trying to use these on the try server to help, but the failures didn't actually happen on the try server for the two pushes I performed (with some minor logging changes between the two).  This either means my logging changes alter timing enough to stop the intermittent oranges, or there is some horrible subtle difference between the try runs and the non-try runs.  (Packages tests versus non-packaged?)

One thing made obvious to me is I'm not sure how to make buildbot just re-run unit tests.  I have access to the admin variant, but all I could see was a way to order it to do a complete rebuild of a push.  I told it to do that for one of the linux builders, but since I haven't seen the results show up yet, I presume it did not work right.  Or I killed buildbot, because I can't get it to respond right now so I can see the buildbot waterfall instead of depending on tinderbox.


Logging improvements:

- Better identify windows by more consistently reporting their window type and by tagging all windows with unique integers that we report.

- Introduced a "b" class of logging for "winhelp" and "fdh" for boring events.  This is really just a presentation thing that's the lesser evil versus complicating the client side a lot more at this point.

- Map keyCode values to VK_CONSTANTS and show charCodes as actual characters for keypress events.

- Log window activation/deactivation.  (Note: only happens once we augment the windows.  The resulting event stream for when a new window shows up tends to be: "window we know about deactivates", "we augment the new window", "we hear about the new window deactivating in favor of some other window we already knew about".    I tried to hook us up during the onOpenWindow event, but could not readily poke our unique id anywhere and do not believe the blind spot is large enough to justify figuring out how to actually make that work at this time.)
Attachment #518927 - Flags: review?(bugzilla)
Comment on attachment 518927 [details] [diff] [review]
logging imporovements round 2, v1

This all looks fine, and seeing as you've passed it through try server, I'm not going to test locally. r=Standard8
Attachment #518927 - Flags: review?(bugzilla) → review+
pushed to trunk:
http://hg.mozilla.org/comm-central/rev/f07a0f76ac47
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.3a4
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: