bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

improve fancy mozmill logging, round 2

RESOLVED FIXED in Thunderbird 5.0b1


Testing Infrastructure
7 years ago
7 years ago


(Reporter: asuth, Assigned: asuth)


Thunderbird 5.0b1

Firefox Tracking Flags

(Not tracked)



(1 attachment)



7 years ago
Created attachment 518927 [details] [diff] [review]
logging imporovements round 2, v1

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+

Comment 2

7 years ago
pushed to trunk:
Last Resolved: 7 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.