Closed Bug 738374 Opened 10 years ago Closed 10 years ago

Random orange: TEST-UNEXPECTED-FAIL | test-message-header.js | test-message-header.js::test_clicking_star_opens_inline_contact_editor


(Thunderbird :: Testing Infrastructure, defect)

Not set


(Not tracked)

Thunderbird 14.0


(Reporter: mconley, Assigned: mconley)


(Keywords: intermittent-failure)


(1 file, 1 obsolete file)

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
Whiteboard: [tb-orange]
Assignee: nobody → mconley
Attached patch Patch v1 (obsolete) — Splinter Review
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 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.
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)
Attachment #609326 - Flags: review?(mbanner) → review+
Moved the helper function to the top of the test file, and added documentation.
Attachment #609326 - Attachment is obsolete: true
Committed to comm-central as
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 14.0
Whiteboard: [tb-orange]
You need to log in before you can comment on or make changes to this bug.