Closed Bug 1094076 Opened 5 years ago Closed 5 years ago
Intermittent failing test, TEST-UNEXPECTED-FAIL | apps/sms/test/marionette/composer
_test .js | Messages Composer Messages Composer Test Suite Message char counter and MMS label
The error log: 21:55:58 INFO - 1) Messages Composer Messages Composer Test Suite Message char counter and MMS label: 21:55:58 INFO - Error: timeout exceeded! 21:55:58 INFO - at Object.Client.waitForSync (/builds/slave/test/gaia/node_modules/marionette-client/lib/marionette/client.js:682:16) 21:55:58 INFO - at Object.Client.waitFor (/builds/slave/test/gaia/node_modules/marionette-client/lib/marionette/client.js:650:60) 21:55:58 INFO - at Object.MarionetteHelper.waitForElement (/builds/slave/test/gaia/node_modules/marionette-helper/index.js:142:12) 21:55:58 INFO - at Object.attachmentMenu (/builds/slave/test/gaia/apps/sms/test/marionette/lib/messages.js:177:32) 21:55:58 INFO - at Object.selectAttachmentMenuOption (/builds/slave/test/gaia/apps/sms/test/marionette/lib/messages.js:205:37) 21:55:58 INFO - at Context.<anonymous> (/builds/slave/test/gaia/apps/sms/test/marionette/composer_test.js:173:19) 21:55:58 INFO - at callFn (/builds/slave/test/gaia/node_modules/mocha/lib/runnable.js:223:21) 21:55:58 INFO - at Test.Runnable.run (/builds/slave/test/gaia/node_modules/mocha/lib/runnable.js:216:7) 21:55:58 INFO - at Runner.runTest (/builds/slave/test/gaia/node_modules/mocha/lib/runner.js:373:10) 21:55:58 INFO - at /builds/slave/test/gaia/node_modules/mocha/lib/runner.js:451:12 21:55:58 INFO - at next (/builds/slave/test/gaia/node_modules/mocha/lib/runner.js:298:14) 21:55:58 INFO - at /builds/slave/test/gaia/node_modules/mocha/lib/runner.js:308:7 21:55:58 INFO - at next (/builds/slave/test/gaia/node_modules/mocha/lib/runner.js:246:23) 21:55:58 INFO - at /builds/slave/test/gaia/node_modules/mocha/lib/runner.js:270:7 21:55:58 INFO - at done (/builds/slave/test/gaia/node_modules/mocha/lib/runnable.js:185:5) 21:55:58 INFO - at callFn (/builds/slave/test/gaia/node_modules/mocha/lib/runnable.js:228:7) 21:55:58 INFO - at Hook.Runnable.run (/builds/slave/test/gaia/node_modules/mocha/lib/runnable.js:216:7) 21:55:58 INFO - at next (/builds/slave/test/gaia/node_modules/mocha/lib/runner.js:258:10) 21:55:58 INFO - at Object._onImmediate (/builds/slave/test/gaia/node_modules/mocha/lib/runner.js:275:5) 21:55:58 INFO - at processImmediate [as _immediateCallback] (timers.js:330:15)  https://treeherder.mozilla.org/ui/#/jobs?repo=gaia-try&revision=7474dcbf4525  http://ftp.mozilla.org/pub/mozilla.org/b2g/try-builds/gaiabld-7474dcbf4525/gaia-try-linux64_gecko/gaia-try_ubuntu64_vm-b2gdt_test-gaia-js-integration-2-bm68-tests1-linux64-build108.txt.gz
Hey Kevin, what's your guidelines to resolve these sorts of intermittents?
Hmm, it could be a number of things. It does look like we have a screenshot which is helpful though, so let's upload that here and cross-reference the code. The screen looks smaller at this point, so my guess is that the keyboard is up. I find it strange that the keyboard isn't displayed though, so maybe for some reason the screenshot is being taken of the sms app itself. I will continue to look into this later today.
Julien - in this case it looks like the sms area does not have enough room to view the attachment, so clicking on it fails here: https://github.com/mozilla-b2g/gaia/blob/master/apps/sms/test/marionette/composer_test.js#L172 Is this expected from a UX point of view? Can the textarea ever get too big to the point where you can no longer see the content above it? See the screenshot attached here, I'm still not sure why it's so small. Additionally we could try causing a manual blur() to remove the keyboard first. We'd need some waitFor() to ensure that the attachment is displayed after the blur I think.
Flags: needinfo?(kgrandon) → needinfo?(felash)
Yeah it's definitely possible. But as you see we call scrollIntoView just before. This actually reminds me of the issues we had on Homescreen. I think that because of APZC we need to sleep for a small moment because scrollIntoView would return before the scroll actually happens. Checking with :kats at the moment.
So Marionette is supposed to do the scroll before tapping. Still I don't know if APZC is producing this issue.
Julien - I'm not sure if scrolling could even help here? If you look at the screenshot, the content area just has *zero* room to display any threads. My assumption is that this is what's causing the issue - we're waiting for content to be displayed, and might end up waiting forever because the keyboard is up?
No, there is no thread involved here because we're in the "new message" panel. What we're scrolling is the composer, trying to tap on an attachment to trigger the menu to remove it :)
Just renaming this so it shows up on the failure list.
Summary: Intermittent failing test, TEST-UNEXPECTED-FAIL | null | Messages Composer Messages Composer Test Suite Message char counter and MMS label → Intermittent failing test, TEST-UNEXPECTED-FAIL | apps/sms/test/marionette/composer_test.js | Messages Composer Messages Composer Test Suite Message char counter and MMS label
This failed 3 times out of 20 in https://treeherder.mozilla.org/ui/#/jobs?repo=gaia-try&revision=7f717ff8d5c7, its very common error inside treeherder and above the intermittent failure rate requirements so disabling Hey Julien, needinfoing so you can assign this / work on getting it fixed, cheers
I'll try to figure out what is going on and how we can fix this
Flags: needinfo?(felash) → needinfo?(azasypkin)
Oleg, see also bug 1046706, maybe this will get fixed soon by Marionette in Gecko?
(In reply to Julien Wajsberg [:julienw] from comment #12) > Oleg, see also bug 1046706, maybe this will get fixed soon by Marionette in > Gecko? It's possible, but I can't be 100% sure as I wasn't able to reproduce it locally to understand the reason. In this quick patch I just hide keyboard and wait until it's fully hidden to avoid any scroll manipulations/dependencies. + I rerun Gij tests on Treeherder for this PR (~35 times) and I see no failures because of this particular test. What do you think?  https://treeherder.mozilla.org/ui/#/jobs?repo=gaia-try&revision=afcd1fde41aa
Comment on attachment 8525137 [details] [review] GitHub pull request URL As discussed on IRC, let's try a simple client.wait first. If that doesn't work then I'm fine with landing your workaround.
(In reply to Julien Wajsberg [:julienw] from comment #17) > Comment on attachment 8525137 [details] [review] > GitHub pull request URL > > As discussed on IRC, let's try a simple client.wait first. > > If that doesn't work then I'm fine with landing your workaround. Yep, client.helper.wait works, the minimum pause time when I don't see intermittent failures anymore is "600ms".
Comment on attachment 8527512 [details] [review] GitHub pull request URL (with timeout) Hey Julien, Could you please make a review of this tiny patch? Thanks!
Attachment #8527512 - Flags: review?(felash)
Attachment #8527512 - Flags: review?(felash) → review+
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
(In reply to Julien Wajsberg [:julienw] from comment #20) > master: > https://github.com/mozilla-b2g/gaia/commit/ > 056ec538fbc63c867ca2670a2f8cf7292b790326 Thanks for landing!
Assignee: nobody → azasypkin
You need to log in before you can comment on or make changes to this bug.