Closed Bug 1290184 Opened 8 years ago Closed 8 years ago

Intermittent test_end for test_windows.py TestWindows.test_windows logged while not in progress. Logged with data: {"status": "ERROR", "extra": {"class_name": "test_windows.TestWindows", "method_name": "test_windows"}

Categories

(Testing :: Firefox UI Tests, defect)

Product:
Testing
Component:
Firefox UI Tests
Version:
Version 3
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 1290186

People

(Reporter: intermittent-bug-filer, Assigned: mconley)

References

Details

(Keywords: intermittent-failure, regression)

I think my work in bug 1261842 is responsible for this. If you look at the log, just before the crash, we get this: JavaScript error: chrome://marionette/content/listener.js, line 1017: NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIWebProgress.removeProgressListener] What I think is going on is that Marionette is noticing that something's gone wrong inside listener.js, and freaks out, and kills the process, which looks like a crash.
Assignee: nobody → mconley
Blocks: 1261842
(In reply to Mike Conley (:mconley) - (Needinfo me!) from comment #1) > What I think is going on is that Marionette is noticing that something's > gone wrong inside listener.js, and freaks out, and kills the process, which > looks like a crash. Yes, that's what I mentioned to you on IRC. The faulty behavior to shutdown Firefox in case of a timeout via Marionette server was introduced in bug 1257476 (see bug 1257476 comment 25). I'm going to fix this part via bug 1202392 and which will hopefully land later today. But, it doesn't fix any timeout failure in listener.js, so this definitely needs its own fix. Thanks Mike for taking this.
Status: NEW → ASSIGNED
Same as bug 1290186.
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.