Closed Bug 1104961 Opened 10 years ago Closed 9 years ago

Intermittent share_activity_test.js | Messages as share target Share via Messages Activity close button Should return to Thread panel if in Participants panel

Categories

(Firefox OS Graveyard :: Gaia::SMS, defect)

Product:
Firefox OS Graveyard
Component:
Gaia::SMS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(b2g-v2.2 fixed, b2g-master fixed)

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
b2g-v2.2 --- fixed
b2g-master --- fixed

People

(Reporter: RyanVM, Assigned: azasypkin)

Details

(Keywords: intermittent-failure, Whiteboard: [sms-sprint-2.2S5])

Attachments

(1 file)

GitHub pull request URL
46 bytes, text/x-github-pull-request
steveck
: review+
Details | Review 
09:58:54 INFO - TEST-START | apps/sms/test/marionette/share_activity_test.js | Messages as share target Share via Messages Activity close button Should close activity if in Composer panel
09:59:37 INFO - TEST-PASS | apps/sms/test/marionette/share_activity_test.js | Messages as share target Share via Messages Activity close button Should close activity if in Composer panel
09:59:37 INFO - TEST-END | apps/sms/test/marionette/share_activity_test.js | Messages as share target Share via Messages Activity close button Should close activity if in Composer panel took 24193 ms
09:59:37 INFO - TEST-START | apps/sms/test/marionette/share_activity_test.js | Messages as share target Share via Messages Activity close button Should close activity if in Thread panel
10:00:02 INFO - TEST-PASS | apps/sms/test/marionette/share_activity_test.js | Messages as share target Share via Messages Activity close button Should close activity if in Thread panel
10:00:02 INFO - TEST-END | apps/sms/test/marionette/share_activity_test.js | Messages as share target Share via Messages Activity close button Should close activity if in Thread panel took 5601 ms
10:00:02 INFO - TEST-START | apps/sms/test/marionette/share_activity_test.js | Messages as share target Share via Messages Activity close button Should return to Thread panel if in Report panel
10:00:31 INFO - TEST-PASS | apps/sms/test/marionette/share_activity_test.js | Messages as share target Share via Messages Activity close button Should return to Thread panel if in Report panel
10:00:31 INFO - TEST-END | apps/sms/test/marionette/share_activity_test.js | Messages as share target Share via Messages Activity close button Should return to Thread panel if in Report panel took 9514 ms
10:00:31 INFO - TEST-START | apps/sms/test/marionette/share_activity_test.js | Messages as share target Share via Messages Activity close button Should return to Thread panel if in Participants panel
10:01:12 INFO - TEST-UNEXPECTED-FAIL | apps/sms/test/marionette/share_activity_test.js | Messages as share target Share via Messages Activity close button Should return to Thread panel if in Participants panel
10:01:12 INFO - Error: Polling socket recv() timeout!
10:01:12 INFO - at TcpSync._readResponse (/builds/slave/test/gaia/node_modules/marionette-client/lib/marionette/drivers/tcp-sync.js:140:30)
10:01:12 INFO - at TcpSync.send (/builds/slave/test/gaia/node_modules/marionette-client/lib/marionette/drivers/tcp-sync.js:153:24)
10:01:12 INFO - at Object.send (/builds/slave/test/gaia/node_modules/marionette-client/lib/marionette/client.js:457:36)
10:01:12 INFO - at Object.Client._sendCommand (/builds/slave/test/gaia/node_modules/marionette-client/lib/marionette/client.js:503:19)
10:01:12 INFO - at Object.Element._sendCommand (/builds/slave/test/gaia/node_modules/marionette-client/lib/marionette/element.js:49:21)
10:01:12 INFO - at Object.sendKeys (/builds/slave/test/gaia/node_modules/marionette-client/lib/marionette/element.js:162:19)
10:01:12 INFO - at Object.addRecipient (/builds/slave/test/gaia/apps/sms/test/marionette/lib/messages.js:222:41)
10:01:12 INFO - at Context.<anonymous> (/builds/slave/test/gaia/apps/sms/test/marionette/share_activity_test.js:107:21)
10:01:12 INFO - at callFn (/builds/slave/test/gaia/node_modules/mocha/lib/runnable.js:223:21)
10:01:12 INFO - at Test.Runnable.run (/builds/slave/test/gaia/node_modules/mocha/lib/runnable.js:216:7)
10:01:12 INFO - at Runner.runTest (/builds/slave/test/gaia/node_modules/mocha/lib/runner.js:373:10)
10:01:12 INFO - at /builds/slave/test/gaia/node_modules/mocha/lib/runner.js:451:12
10:01:12 INFO - at next (/builds/slave/test/gaia/node_modules/mocha/lib/runner.js:298:14)
10:01:12 INFO - at /builds/slave/test/gaia/node_modules/mocha/lib/runner.js:308:7
10:01:12 INFO - at next (/builds/slave/test/gaia/node_modules/mocha/lib/runner.js:246:23)
10:01:12 INFO - at /builds/slave/test/gaia/node_modules/mocha/lib/runner.js:270:7
10:01:12 INFO - at done (/builds/slave/test/gaia/node_modules/mocha/lib/runnable.js:185:5)
10:01:12 INFO - at callFn (/builds/slave/test/gaia/node_modules/mocha/lib/runnable.js:228:7)
10:01:12 INFO - at Hook.Runnable.run (/builds/slave/test/gaia/node_modules/mocha/lib/runnable.js:216:7)
10:01:12 INFO - at next (/builds/slave/test/gaia/node_modules/mocha/lib/runner.js:258:10)
10:01:12 INFO - at Object._onImmediate (/builds/slave/test/gaia/node_modules/mocha/lib/runner.js:275:5)
10:01:12 INFO - at processImmediate [as _immediateCallback] (timers.js:330:15)
10:01:12 INFO - TEST-END | apps/sms/test/marionette/share_activity_test.js | Messages as share target Share via Messages Activity close button Should return to Thread panel if in Participants panel took 22495 ms
Let's see how frequent this is.
Seems like there are bunch of patch failed for now, maybe it's because we're waiting for element within an activity but the activity already exited.
(In reply to Steve Chung [:steveck] from comment #11)
> Seems like there are bunch of patch failed for now, maybe it's because we're
> waiting for element within an activity but the activity already exited.

Yeah, looking into it. I see different failures in logs, but one of them ("unload was called") is definitely because of the fact that we have reference to marionette element that belongs to activity window that was closed.
Updated PR with the fix for one more intermittent "The element reference is stale" failure in tests that use recipient input. Recipients.js re-renders its entire content once recipient is added or removed and it can do it several times for single "add/remove" operation (!!!). So it looks like that recipient node is removed and re-created again somewhere between the moment we get element reference with "waitForElement/findElement" and then call "el.displayed()".
Comment on attachment 8555329 [details] [review]
GitHub pull request URL

Hey Steve, I don't see intermittent failures in the test with this patch. See [1] (Gij-5).

How do you feel about it?

[1] https://treeherder.mozilla.org/ui/#/jobs?repo=gaia-try&revision=e9c0902b8de8
Attachment #8555329 - Flags: review?(schung)
Adding this kind of timeout in tests should be discouraged. If we can't make the proper recipients.js fix, it would be better to create some kind of hook where we could do a client.helper.waitFor() on. E.g., you could have some data attribute which defines what the currently rendered recipients are, and then wait on that. E.g., <section data-query="some search term">
(In reply to Kevin Grandon :kgrandon [INACTIVE - heads down on Gij Issue] from comment #17)
> Adding this kind of timeout in tests should be discouraged. If we can't make
> the proper recipients.js fix, it would be better to create some kind of hook
> where we could do a client.helper.waitFor() on. E.g., you could have some
> data attribute which defines what the currently rendered recipients are, and
> then wait on that. E.g., <section data-query="some search term">

Yeah, I know. It's definitely bad and we always try to avoid that in our tests. AFAIK we don't have any hook for this, but still trying to find better solution in the meantime.
The less-intrusive fix for recipients.js that I have in mind is just try to throttle recipients.render call somehow
I'm ok with the mutation observe to wait for recipient stable, but please keep the compose test in the blacklist and fix in bug 1121766 instead.
Assignee: nobody → azasypkin
Comment on attachment 8555329 [details] [review]
GitHub pull request URL

Looks fine currently, and we can refine the recipients with better integration test in the future, thanks!
Attachment #8555329 - Flags: review?(schung) → review+
Thanks for review! Okay, let's how it goes. Will take a closer look at recipients.js to fix the root cause, but it's safer to have this test enabled in the meantime.

Master: https://github.com/mozilla-b2g/gaia/commit/c67885f291c4a0389df8bb7b213b19a1693e9dc5
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Whiteboard: [sms-sprint-2.2S5]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: