Filed by: hskupin [at] mozilla.com https://treeherder.mozilla.org/logviewer.html#?job_id=175780324&repo=try https://queue.taskcluster.net/v1/task/P1iMfgqCQxCgEvN-jPJSYQ/runs/0/artifacts/public/logs/live_backing.log

Those two tests will be disabled by the next wptsync merge as covered by bug 1453105. Is it actually a new type of failure we haven't seen before. So I wonder if something else landed on the canonical repository, which triggered those failures.

Both tests have been disabled based on the wptsync merge from bug 1453105. See also bug 1431081 for another reason.

(In reply to Henrik Skupin (:whimboo) from comment #3) > Both tests have been disabled based on the wptsync merge from bug 1453105. > See also bug 1431081 for another reason. Strange. Given bug 1459118 the tests should still be active. I will have to check that later.

The test has been disabled by the landing of my patch on bug 1459118.

This test is disabled and as such doesn't show the failures.

These tests will be re-enabled together with the execute_script ones over on bug 1459118.

We are trying to build a tool to automatically classify intermittent failures, which would provide a starting point for fixing the bug, reducing the manual work for the developers. We are collecting some feedback on the results, to see if they’re good enough and where we need to improve. For this bug, the tool says that the intermittent failure is most likely a: Concurrency Issue: This includes tests in which failures occur due to thread management issues (different threads or their outcomes depending on an implicit ordering), race conditions and/or deadlocks, and issues related to an asynchronous waits (e.g. a process trying to access an external resource or continuing before the external resource is available). Once you’re done investigating and/or fixing the bug, could you tell me: - Did the tool correctly recognize the type of intermittent failure? - Did the information from the tool help your analysis, the bug fixing process, or anything in the process? (please also let us know how the tool was useful and/or what would improve the tool's usefulness for you)

(In reply to meck93 from comment #11) Once you’re done investigating and/or fixing the bug, could you tell me: > - Did the tool correctly recognize the type of intermittent failure? Which tool? And where to gather that information? There has nothing pointed out. > - Did the information from the tool help your analysis, the bug fixing > process, or anything in the process? Again, nothing to tell without details about the tool.

@[:whimboo]: Comment #11 was a post created by the tool. The tool analyses the Treeherder logfiles (+ affected source code files) and tries to predict the most likely type of intermittent-failure, which is then posted as a comment #11. For this bug, the prediction was: a concurrency issue.

Yes as of it's state now it might be a concurrency issue. In some cases the command returns too early and as such not two dialogs have been opened.

It's not clear by the spec, so I cannot continue to work on this bug for now.

This is actually blocked by bug 1487358 if opening two alerts is the expected behavior. The discussion is still ongoing on bug https://github.com/w3c/webdriver/issues/1153.

Moving bug to Remote Protocol::Marionette component per bug 1815831.