Closed Bug 1085667 Opened 10 years ago Closed 9 years ago

Intermittent failing test, TEST-UNEXPECTED-FAIL | /home/tester/git_checkout/apps/ringtones/test/marionette/share_test.js | Share as ringtone Share activity Create new ringtone

Categories

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

x86
macOS
defect
Not set
normal

Tracking

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

RESOLVED FIXED
2.1 S7 (24Oct)
Tracking Status
b2g-v2.1 --- fixed
b2g-v2.2 --- fixed

People

(Reporter: kgrandon, Assigned: kgrandon)

References

Details

(Keywords: intermittent-failure, Whiteboard: [systemsfe])

Attachments

(4 files)

Share as ringtone Share activity Create new ringtone: NoSuchElement: (7) Unable to locate element: form[data-z-index-level="action-menu"] Remote Stack: <none> at Error.MarionetteError (/home/tester/git_checkout/node_modules/marionette-client/lib/marionette/error.js:67:13) at Object.Client._handleCallback (/home/tester/git_checkout/node_modules/marionette-client/lib/marionette/client.js:476:19) at /home/tester/git_checkout/node_modules/marionette-client/lib/marionette/client.js:510:21 at TcpSync.send (/home/tester/git_checkout/node_modules/marionette-client/lib/marionette/drivers/tcp-sync.js:153:10) at Object.send (/home/tester/git_checkout/node_modules/marionette-client/lib/marionette/client.js:457:36) at Object.Client._sendCommand (/home/tester/git_checkout/node_modules/marionette-client/lib/marionette/client.js:503:19) at Object._findElement (/home/tester/git_checkout/node_modules/marionette-client/lib/marionette/client.js:1303:19) at Object.findElement (/home/tester/git_checkout/node_modules/marionette-client/lib/marionette/client.js:1352:32) at Object.MarionetteHelper.waitForElement (/home/tester/git_checkout/node_modules/marionette-helper/index.js:139:19) at Object.shareMenu (/home/tester/git_checkout/apps/music/test/marionette/lib/music.js:82:31) at Object.Music.shareWith (/home/tester/git_checkout/apps/music/test/marionette/lib/music.js:208:20) at Context.<anonymous> (/home/tester/git_checkout/apps/ringtones/test/marionette/share_test.js:44:16) at callFn (/home/tester/git_checkout/node_modules/mocha/lib/runnable.js:223:21) at Test.Runnable.run (/home/tester/git_checkout/node_modules/mocha/lib/runnable.js:216:7) at Runner.runTest (/home/tester/git_checkout/node_modules/mocha/lib/runner.js:373:10) at /home/tester/git_checkout/node_modules/mocha/lib/runner.js:451:12 at next (/home/tester/git_checkout/node_modules/mocha/lib/runner.js:298:14) at /home/tester/git_checkout/node_modules/mocha/lib/runner.js:308:7 at next (/home/tester/git_checkout/node_modules/mocha/lib/runner.js:246:23) at Object._onImmediate (/home/tester/git_checkout/node_modules/mocha/lib/runner.js:275:5) at processImmediate [as _immediateCallback] (timers.js:336:15) https://taskcluster-artifacts.s3-us-west-2.amazonaws.com/QZ8nN-KKTdGQKIY5dRK0uQ/2/public/marionette_js_tests/debug.log?AWSAccessKeyId=AKIAIZOQG4W6WG3PH3RQ&Expires=1413842176&Signature=gn%2BXUNp54Hgyf7RobpPIRPYH7ew%3D
Blocks: 1076681
Attached file Github pull request
Comment on attachment 8508313 [details] [review] Github pull request Dominic - would you happen to have a few minutes to review this? I think the main problem is with the showing/hiding of the share button. If we perform the action too early or too late, the test can fail. This will retry the action a few times, and tap on the album cover to show the button again if it disappears.
Attachment #8508313 - Flags: review?(dkuo)
Comment on attachment 8508313 [details] [review] Github pull request Or Jim - Maybe you could review this if you have time since the timezones are a better match? Thanks!
Attachment #8508313 - Flags: review?(squibblyflabbetydoo)
Comment on attachment 8508313 [details] [review] Github pull request Sorry for the late reply, and I am reviewing it.
Attachment #8508313 - Flags: review?(squibblyflabbetydoo)
Comment on attachment 8508313 [details] [review] Github pull request Kevin, thanks for fixing this issue, the patch does the right action to make the share button displayed before the client tap it, so looks good to me! I didn't actually look on the try results but hope this can solve the intermittent failings.
Attachment #8508313 - Flags: review?(dkuo) → review+
Assignee: nobody → kgrandon
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [systemsfe]
Target Milestone: --- → 2.1 S7 (24Oct)
This is happening on v2.1 pretty often. Let's try to uplift.
Blocks: 1103962
Attached file [Gaia v2.1 PR] Uplift
Let's see if this helps.
Blocks: 1109925
No longer blocks: 1076681
fabrice, cwiiis, this seems to fail frequently now again, do you know what could have caused this ?
Status: RESOLVED → REOPENED
Flags: needinfo?(fabrice)
Flags: needinfo?(chrislord.net)
Resolution: FIXED → ---
Not off-hand, but if it's dialog-related, I wonder if bug 1196268 has anything to do with it? (I kind of doubt it, but without looking or knowing much about this part of the system, that's my best guess) Maybe someone that works on the Settings app might have some more insight?
some retriggeres pointing back to https://hg.mozilla.org/integration/b2g-inbound/rev/8f95bc3af1b2 but i don't see any obvious in there, Fabrice do you know ?
No idea, no. sorry :( Passing the bucket to mhenretty...
Flags: needinfo?(fabrice) → needinfo?(mhenretty)
Flags: needinfo?(chrislord.net)
Attached file gdb bt
Naveed, that seems like a bad race condition in the JS engine.
Flags: needinfo?(nihsanullah)
Hm seems like we have multiple issues here. Let me confirm the stack first.
Flags: needinfo?(nihsanullah)
Attached file gdb bt
The top of the stack seems to vary but all the crashes seem to have in common that we are creating an exception.
:nbp, can you take a look here?
Flags: needinfo?(nicolas.b.pierron)
frame #9: 0x0000000102d38126 XUL`mozilla::dom::Exception::Exception(this=0x0000000114ed2c60, aMessage=0x00007fff5fbf6220, aResult=2152857608, aName=0x000000010839f9f0, aLocation=<unavailable>, aData=0x0000000000000000) + 582 at DOMException.cpp:222 219 if (aLocation) { 220 location = aLocation; 221 } else { -> 222 location = GetCurrentJSStack(); 223 // it is legal for there to be no active JS stack, if C++ code 224 // is operating on a JS-implemented interface pointer without 225 // having been called in turn by JS. This happens in the JS (lldb) p aMessage (const nsACString_internal) $0 = "Component returned failure code: 0x80520008 (NS_ERROR_FILE_ALREADY_EXISTS) [nsIFile.create]"
Why does the stack trace ends with a SIGKILL?
Please note that backing out [1] fixes the issue, so this most likely has something to do with the CSS calc call in the translateY transform. I didn't try it with replacing the css variable with a constant, so let me know if anyone wants me to. 1.) https://github.com/mozilla-b2g/gaia/commit/3c68cb33f23b8a85271d3243a53ba1a5ddb9b681
Flags: needinfo?(mhenretty)
(In reply to Michael Henretty [:mhenretty] from comment #168) > Please note that backing out [1] fixes the issue, so this most likely has > something to do with the CSS calc call in the translateY transform. I didn't > try it with replacing the css variable with a constant, so let me know if > anyone wants me to. > > 1.) > https://github.com/mozilla-b2g/gaia/commit/ > 3c68cb33f23b8a85271d3243a53ba1a5ddb9b681 reverted this now, thanks michael!
Blocks: 1188603
Flags: needinfo?(nicolas.b.pierron)
Closing this based on comment 185.
Status: REOPENED → RESOLVED
Closed: 10 years ago9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: