Closed
Bug 738374
Opened 13 years ago
Closed 13 years ago
Random orange: TEST-UNEXPECTED-FAIL | test-message-header.js | test-message-header.js::test_clicking_star_opens_inline_contact_editor
Categories
(Thunderbird :: Testing Infrastructure, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
Thunderbird 14.0
People
(Reporter: mconley, Assigned: mconley)
Details
(Keywords: intermittent-failure)
Attachments
(1 file, 1 obsolete file)
4.78 KB,
patch
|
Details | Diff | Splinter Review |
Stack of test failure:
SUMMARY-UNEXPECTED-FAIL | test-message-header.js | test-message-header.js::test_clicking_star_opens_inline_contact_editor
EXCEPTION: address not updated after clicking star
at: test-message-header.js line 605
subtest_more_widget_star_click([object XULElement]) test-message-header.js 605
test_clicking_star_opens_inline_contact_editor() test-message-header.js 198
frame.js 557
frame.js 626
frame.js 669
frame.js 497
frame.js 675
server.js 179
server.js 183
Assignee | ||
Updated•13 years ago
|
Whiteboard: [tb-orange]
Assignee | ||
Updated•13 years ago
|
Assignee: nobody → mconley
Assignee | ||
Comment 1•13 years ago
|
||
This seems to address this issue...
What confuses me is why the test passes *sometimes*. When the tests failed for me locally, it looked like this was due to the fact that the wrong "lastAddr" was being selected (due to the multi-address-in-header thing having some hidden address nodes from previously selected messages...is that an optimisation of some kind?).
So I've added a function that selects the last address in the multi-address-in-header node that is actually visible. Seems to fix the issue.
Mark - I *think* this is code you've worked on before...any idea if I'm missing anything, or why we'd only sometimes fail this test (and only on Linux?)
Attachment #609326 -
Flags: feedback?(mbanner)
The caching of address nodes should be more predictable after bug 732144 does no longer take into account temporary expansions by the "more" button. Whether or not the cached length is larger than the displayed address list depends on what that widget encountered before in its life time (i.e., when was it instantiated and what happened since?). Even if you'd disable caching entirely and always have a "fresh" instance of the widget, it may still happen that the last address node turned back to a "hidden" status due to bug 567062 or bug 601206. These are fringe cases which depend on window width, font characteristics, etc., thus may certainly differ among platforms as seen in this case.
Thus, figuring out how many nodes are really displayed to avoid selecting a hidden node for the test seems to be the correct approach here either way.
Assignee | ||
Comment 3•13 years ago
|
||
Comment on attachment 609326 [details] [diff] [review]
Patch v1
I'm encouraged enough by rsx11m's comment enough to skip feedback, and go right for r?. :)
Attachment #609326 -
Flags: feedback?(mbanner) → review?(mbanner)
Updated•13 years ago
|
Attachment #609326 -
Flags: review?(mbanner) → review+
Assignee | ||
Comment 4•13 years ago
|
||
Moved the helper function to the top of the test file, and added documentation.
Attachment #609326 -
Attachment is obsolete: true
Assignee | ||
Comment 5•13 years ago
|
||
Committed to comm-central as http://hg.mozilla.org/comm-central/rev/ba68f54303d7
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 14.0
Comment hidden (Legacy TBPL/Treeherder Robot) |
Updated•12 years ago
|
Keywords: intermittent-failure
Updated•12 years ago
|
Whiteboard: [tb-orange]
Comment hidden (Legacy TBPL/Treeherder Robot) |
You need to log in
before you can comment on or make changes to this bug.
Description
•