These assertions are appearing on Win7/8 Debug following landing bug 1039666, which enabled Window and Screen sharing tests (winXP window/screensharing is disabled) https://tbpl.mozilla.org/php/getParsedLog.php?id=45112940&full=1&branch=mozilla-inbound 22:39:23 INFO - 9613 INFO [Parent 3708] ###!!! ASSERTION: Received "nonqueued" message 14 during a synchronous IPC message for window 5701686 ("MozillaWindowClass"), sending it to DefWindowProc instead of the normal window procedure.: 'Error', file c:/builds/moz2_slave/m-in-w32-d-0000000000000000000/build/ipc/glue/WindowsMessageLoop.cpp, line 186 It's unclear why these didn't appear in earlier Try runs (win7/8 were solid green), and they're not 100% orange (perhaps 75-90%?). All tests complete successfully.

FYI, bug 874437 tracks similar asserts we hit intermittently during the plugin tests too. Though those are always on WinXP IIRC.

This message doesn't sound too critical, can probably just pass straight to DefWindowProc. http://msdn.microsoft.com/en-us/library/windows/desktop/ms632628%28v=vs.85%29.aspx

Right now I've suppressed one assertion max on the tests; who can own this bug? When this landed, we should back out the suppression landed as part of bug 1039666. Note that these assertions will make using this in a Debug Win32 build painful.

Bug 1041369 increased the frequency of these asserts, so I bumped the max up to 3.

this and bug 1050247 are the same, they both correspond to the unhandled text length message. 09:17:04 INFO - 11822 INFO [Parent 448] ###!!! ASSERTION: Received "nonqueued" ui message "WM_GETTEXTLENGTH" during a synchronous IPC message for window 0x1016C ("MozillaWindowClass"), sending it to DefWindowProc instead of the normal window procedure.: 'Error', file c:/builds/moz2_slave/try-w32-d-00000000000000000000/build/ipc/glue/WindowsMessageLoop.cpp, line 208

easy peasy, one liner. from MSDN: -- For an edit control, the text to be copied is the content of the edit control. For a combo box, the text is the content of the edit control (or static-text) portion of the combo box. For a button, the text is the button name. **For other windows, the text is the window title.** -- Pretty sure this is window title text related. We hand this to DefWindowProc in widget as well so this should be ok. I'm curious if we'll see any new message issues related to retrieving the text after this lands. Shouldn't be a big deal to fix if we do.

Please nominate this for Aurora uplift when you get a chance :)

Comment on attachment 8471785 [details] [diff] [review] patch v.1 Approval Request Comment [Feature/regressing bug #]: Long standing bug, not a regression. [User impact if declined]: Minimal. Tree management oriented. [Describe test coverage new/current, TBPL]: After multiple test runs the issue doesn't reproduce with the patch applied. [Risks and why]: Very low risk of regressions. [String/UUID change made/needed]: None.

Remove the unneeded assertion annotations. https://hg.mozilla.org/integration/mozilla-inbound/rev/a39d2cf1181e

https://hg.mozilla.org/releases/mozilla-aurora/rev/68689e07ffec https://hg.mozilla.org/releases/mozilla-aurora/rev/eb36729316d6