Closed Bug 496058 Opened 10 years ago Closed 10 years ago

mochitest-browser-chrome: browser_bookmarksProperties.js times out intermittently

Categories

(Firefox :: Bookmarks & History, defect, major)

x86
Linux
defect
Not set
major

Tracking

()

VERIFIED FIXED
Firefox 3.6a1
Tracking Status
status1.9.1 --- .3-fixed

People

(Reporter: kinetik, Assigned: mak)

References

(Depends on 1 open bug, )

Details

(Keywords: intermittent-failure, verified1.9.1)

Attachments

(2 files, 1 obsolete file)

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
Whiteboard: [orange]
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/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");
}
Blocks: 438871
Depends on: 492467
Summary: mochitest-browser-chrome: Timeout running browser_bookmarksProperties.js → mochitest-browser-chrome: browser_bookmarksProperties.js times out intermittently
Whiteboard: [orange] → [ToDo: comment 3] [orange]
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=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!
Severity: normal → major
Flags: wanted-firefox3.6?
(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.
Depends on: 495751
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.
Assignee: nobody → mak77
Status: NEW → ASSIGNED
Attachment #385003 - Flags: review?(dietrich)
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.
Attachment #385003 - Flags: review?(dietrich) → review+
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.
Attached patch experimental patch (obsolete) — Splinter Review
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.
Attachment #385821 - Flags: review?(adw)
           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.
Attachment #385821 - Attachment is obsolete: true
Attachment #385826 - Flags: review?(enndeakin)
Attachment #385821 - Flags: review?(adw)
Attachment #385826 - Flags: review?(enndeakin) → review+
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.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.6a1
(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.
Flags: wanted-firefox3.6? → in-testsuite+
Whiteboard: [ToDo: comment 3] [orange] → [ToDo: comment 19] [orange]
Attachment #385826 - Attachment description: experimental patch 2 → experimental patch 2 [Checkin: Comment 18]
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.
Whiteboard: [ToDo: comment 19] [orange] → [ToDo: comment 19] [needs 1.9.1.x landing] [orange]
Whiteboard: [ToDo: comment 19] [needs 1.9.1.x landing] [orange] → [orange]
No orangeness since two weeks on 1.9.1 and trunk. Lets call it verified fixed.
Status: RESOLVED → VERIFIED
Keywords: verified1.9.1
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
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.