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
Created attachment 609326 [details] [diff] [review] Patch v1 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.
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+
Created attachment 613295 [details] [diff] [review] Patch v2 (carrying over r+ from Standard8) 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 http://hg.mozilla.org/comm-central/rev/ba68f54303d7
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 14.0
You need to log in before you can comment on or make changes to this bug.