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

RESOLVED FIXED in Thunderbird 14.0

Status

Thunderbird
Testing Infrastructure
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: mconley, Assigned: mconley)

Tracking

({intermittent-failure})

Trunk
Thunderbird 14.0
x86
Linux
intermittent-failure

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Assignee)

Description

5 years ago
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

5 years ago
Whiteboard: [tb-orange]
(Assignee)

Updated

5 years ago
Assignee: nobody → mconley
(Assignee)

Comment 1

5 years ago
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)

Comment 2

5 years ago
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

5 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)
Attachment #609326 - Flags: review?(mbanner) → review+
(Assignee)

Comment 4

5 years ago
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
(Assignee)

Comment 5

5 years ago
Committed to comm-central as http://hg.mozilla.org/comm-central/rev/ba68f54303d7
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 14.0
Comment hidden (Treeherder Robot)
Keywords: intermittent-failure
Whiteboard: [tb-orange]
Comment hidden (Treeherder Robot)
You need to log in before you can comment on or make changes to this bug.