Closed Bug 1162067 Opened 9 years ago Closed 9 years ago

Intermittent test_Debugger.Source.prototype.element.html | top frame belongs to isolde - expected PASS

Categories

(DevTools :: Debugger, defect)

Product:
DevTools
Component:
Debugger
Platform:
Unspecified
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(firefox38 unaffected, firefox38.0.5 unaffected, firefox39 unaffected, firefox40 fixed, firefox-esr31 unaffected, firefox-esr38 unaffected)

Status:
RESOLVED FIXED
Milestone:
Firefox 40
Tracking Flags:
Tracking Status
firefox38 --- unaffected
firefox38.0.5 --- unaffected
firefox39 --- unaffected
firefox40 --- fixed
firefox-esr31 --- unaffected
firefox-esr38 --- unaffected

People

(Reporter: cbook, Assigned: jimb)

References

(
URL
)

Details

(Keywords: intermittent-failure)

Attachments

(2 files)

Add some debugging output to test_Debugger.Source.prototype.element.html, to catch intermittent failures.
2.32 KB, patch
jlong
: review+
Details | Diff | Splinter Review
Ensure test_Debugger.Source.prototype.element.html doesn't get confused by genuine resize events.
3.32 KB, patch
jlong
: review+
Details | Diff | Splinter Review 
Windows 7 32-bit mozilla-central pgo test mochitest-other

https://treeherder.mozilla.org/logviewer.html#?job_id=1443947&repo=mozilla-central

07:09:53 INFO - 2948 INFO TEST-UNEXPECTED-FAIL | toolkit/devtools/server/tests/mochitest/test_Debugger.Source.prototype.element.html | top frame belongs to isolde - expected PASS
Jim, any ideas what might have made this start happening in the last day or so?
Component: Developer Tools → Developer Tools: Debugger
Flags: needinfo?(jimb)
In this test, bits of test code located in various places (inline script; out-of-line script; dynamically inserted script elements; etc. etc.) each execute a 'debugger' statement, and then the test tries to find the DOM element that owns that bit of test code: usually a <script> element, but possibly some other kind of element with an 'onclick' handler, or what have you.

I have no idea why it would be intermittent. I think we just need to reproduce and debug.
Flags: needinfo?(jimb)
Comment on attachment 8602304 [details] [diff] [review]
Add some debugging output to test_Debugger.Source.prototype.element.html, to catch intermittent failures.

Review of attachment 8602304 [details] [diff] [review]:
-----------------------------------------------------------------

Looks fine to me
Attachment #8602304 - Flags: review?(jlong) → review+
Keywords: leave-open
Okay, I may have a solution. The test establishes an onresize handler, and then sends a synthetic onresize event. But if a real resize happened to occur while the test was running, then that would screw things up. I'm going to try adapting the test to use a different event (the specific event was really an arbitrary choice), and see if that helps.
Actually, the specific event isn't an arbitrary choice. It needs to be one of the events that, when set on a body element, actually adds the handler to the window, not the element. The test verifies that Debugger.Source.prototype.element returns the body element, even though the handler has been placed elsewhere.

I think the test can just explicitly check that the event is synthetic; then it won't be disturbed by genuine resizes.
This is not beautiful; the comments should explain.
Assignee: nobody → jimb
Status: NEW → ASSIGNED
Attachment #8603153 - Flags: review?(jlong)
Comment on attachment 8603153 [details] [diff] [review]
Ensure test_Debugger.Source.prototype.element.html doesn't get confused by genuine resize events.

Review of attachment 8603153 [details] [diff] [review]:
-----------------------------------------------------------------

Sounds good to me. I don't really mind kludges in test code (especially small ones). What made this happen in the first place?
Attachment #8603153 - Flags: review?(jlong) → review+
Don't remember the bug number offhand, but smaug landed a something recently that caused another resize-related intermittent. He fixed it by using RAF IIRC.
Yeah, resize should be dispatched right before rAF callbacks, but I may actually back out the change, and reland after the merge.
Okay, this should hopefully quiet things down:
https://hg.mozilla.org/integration/mozilla-inbound/rev/195378b66079
Seems to have solved the problem. This fix is fine even if Smaug backs out the other change. Closing for now.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Removing leave-open keyword from resolved bugs, per :sylvestre.
Keywords: leave-open
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: