This looks similar to existing bugs filed on this (specifically bug 493355), but not exactly the same, so I'm filing a new bug. This timed out on a Linux unit test machine during a cycle with my patch in it, with no failure in the previous cycle. Since I doubt my patch could've caused this, I'm calling it a random timeout. The timeout happened after the following output: Starting test browser_bookmarksProperties.js *** TEST: Bug 479348 - Properties on a root should be read-only *** TEST: Bug 462662 - Pressing Enter to select tag from autocomplete closes bookmarks properties dialog About to focus the tagsField About to focus the autocomplete results tree *** TEST: Bug 475529 - Add button in new folder dialog not default anymore About to focus the namePicker field *** TEST: Bug 476020 - Pressing Esc while having the tag autocomplete open closes the bookmarks panel About to focus the tagsField command timed out: 1200 seconds without output, killing pid 11908 process killed by signal 9 This was on Linux mozilla-central unit test on 2009/06/02 15:37:11: http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1243982231.1243989243.29475.gz

linux has issues with focus, sadly, so it's possible. i added those dumps "about to focus" exactly to notice if that happens.

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1244473503.1244479386.22946.gz Linux mozilla-central unit test on 2009/06/08 08:05:03

{ http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1244900001.1244907564.30832.gz Linux mozilla-central unit test on 2009/06/13 06:33:21 [...] TEST-PASS | chrome://mochikit/content/browser/browser/components/places/tests/browser/browser_bookmarksProperties.js | *** TEST: Bug 462662 - Pressing Enter to select tag from autocomplete closes bookmarks properties dialog [...] TEST-PASS | chrome://mochikit/content/browser/browser/components/places/tests/browser/browser_bookmarksProperties.js | EditItemOverlay is initialized About to focus the tagsField command timed out: 1200 seconds without output, killing pid 15504 } ***** While here, the 2 following lines are not needed anymore: { 532 dump("Starting test browser_bookmarksProperties.js\n"); 553 dump("*** TEST: " + gCurrentTest.desc + "\n"); }

unless we fix focus issues on Linux, we could simply disable this test on Linux, but since this does not look failing so often, we would lose a valuable test to fix a rare orange. Or we could try with a polling focus method that will issue focus() till the field is focused, with a timeout of 1s. I tried some time ago to force the autocomplete field to open a filled popup without having to focus and synthesizekey to it, but was unable, if you have hints to do so they will be appreciated and will allow to remove those focus calls.

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.5-Unittest/1245460989.1245463378.10592.gz Linux mozilla-1.9.1 test everythingelse on 2009/06/19 18:23:09

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1245707687.1245714489.9191.gz Linux mozilla-central unit test on 2009/06/22 14:54:47

{ http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1245761468.1245764247.30911.gz Linux mozilla-central test everythingelse on 2009/06/23 05:51:08 ... *** TEST: Bug 475529 - Add button in new folder dialog not default anymore TEST-PASS | ... | Sidebar tree has been loaded TEST-PASS | ...| We have a places node selected: Unsorted Bookmarks TEST-PASS | ...| command 'placesCmd_new:folder' on current selected node is enabled TEST-PASS | ...| EditItemOverlay is initialized About to focus the namePicker field command timed out: 1200 seconds without output, killing pid 488 } This one crashed later. Anyway, please fix or disable this test which aborts the test suite!

(In reply to comment #7) > This one crashed later. where is the crash stack? i can't see any evidence of crashes, could you please paste the dump?

(In reply to comment #4) > unless we fix focus issues on Linux, we could simply disable this test on > Linux, but since this does not look failing so often, we would lose a valuable > test to fix a rare orange. Have you filed a bug about the focus issues you're seeing? Are those regressions from FocusManager landing?

(In reply to comment #9) > (In reply to comment #4) > Have you filed a bug about the focus issues you're seeing? Are those > regressions from FocusManager landing? No, focus on Linux has always been problematic (maybe Gtk issues?), as far as i can recall, if you search "focus linux" on bugzilla you can find enough bugs, some old enough to make you cry. I'm not sure filing a new generic focus bug would bring anywhere, unless we have a way to reproduce other than a sometimes failing test. Fixing bug 495751 could be a good start, though.

Till the underlying bug is fixed, we can disable tests that are focusing textfields in Linux. Also removed dump()s that are no more useful.

Comment on attachment 385003 [details] [diff] [review] disable focusing tests on Linux. r=me, contingent upon filing a followup and making it block that linux bug.

before disabling the test i'd like to try sending a focus() call to the window, Neil in another bug wrote "On Linux, window focusing can occur after the load event and other things have occurred.". Worth a try.

i'd like to try this before disabling the test, it's simply focusing the dialog window before running each test. If this won't change a thing i'll push the above disabling patch.

var win = aSubject.QueryInterface(Ci.nsIDOMWindow); win.addEventListener("load", function onLoad(event) { win.removeEventListener("load", onLoad, false); + win.focus(); As this is a new window, you can also just wait for the focus event rather than the load event.

i suppose the focus event will come after load on all platforms, then.

experimental patch 2 checked-in: http://hg.mozilla.org/mozilla-central/rev/d54a92a63aa7 resolving, but anyone still seeing this failure on mozilla-central should reopen this, then i'll proceed disabling test on Linux with the above patch.

(In reply to comment #8) > (In reply to comment #7) > > This one crashed later. > > where is the crash stack? i can't see any evidence of crashes, could you please > paste the dump? Sorry, I meant "hang". (In reply to comment #11) > Also removed dump()s that are no more useful. Could you actually do it? Maybe also replace ok(true, "*** FINISHED TEST ***"); ok(true, "*** TEST: " + gCurrentTest.desc); by ok(true, "End of test: " + gCurrentTest.desc); ok(true, "Start of test: " + gCurrentTest.desc); Thanks.

oh, the disabling patch was doing that, i forgot in the new one, i'll wait a week, if the orange happens i'll push the above, otherwise i'll fix those dumps.

i asked Mossop to add those changes while he's replacing dumps in Bug 481406.

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.5/1249733048.1249740064.4061.gz Linux mozilla-1.9.1 unit test on 2009/08/08 05:04:08

synced test on 1.9.1 http://hg.mozilla.org/releases/mozilla-1.9.1/rev/b95ed9dcf966

No orangeness since two weeks on 1.9.1 and trunk. Lets call it verified fixed.

Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h". In Thunderbird 3.0b, you do that as follows: Tools | Message Filters Make sure the correct account is selected. Click "New" Conditions: Body contains places-to-b-and-h Change the action to "Delete Message". Select "Manually Run" from the dropdown at the top. Click OK. Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter. Gerv

Rev3 Fedora 12 mozilla-central opt test mochitest-other on 2010/05/22 14:18:38 http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1274563118.1274564458.28920.gz