Closed Bug 1230441 Opened 10 years ago Closed 7 years ago

Intermittent e10s browser_dbg_reload-same-script.js | The selected source isn't the correct one etc.

Categories

(DevTools :: Debugger, defect, P5)

Product:
DevTools
Component:
Debugger
Type:
defect

Tracking

(firefox45 affected)

Status:
RESOLVED INVALID
Tracking Flags:
Tracking Status
firefox45 --- affected

People

(Reporter: philor, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: intermittent-failure)

https://treeherder.mozilla.org/logviewer.html#?job_id=2825224&repo=mozilla-central 117 INFO TEST-UNEXPECTED-FAIL | devtools/client/debugger/test/mochitest/browser_dbg_reload-same-script.js | The selected source isn't the correct one (5). - Got http://example.com/browser/devtools/client/debugger/test/mochitest/code_script-switching-01.js, expected http://example.com/browser/devtools/client/debugger/test/mochitest/code_script-switching-02.js 122 INFO TEST-UNEXPECTED-FAIL | devtools/client/debugger/test/mochitest/browser_dbg_reload-same-script.js | The preferred source url wasn't set correctly (6). - Got http://example.com/browser/devtools/client/debugger/test/mochitest/code_script-switching-01.js, expected http://example.com/browser/devtools/client/debugger/test/mochitest/code_script-switching-02.js 123 INFO TEST-UNEXPECTED-FAIL | devtools/client/debugger/test/mochitest/browser_dbg_reload-same-script.js | The selected source isn't the correct one (6). - Got http://example.com/browser/devtools/client/debugger/test/mochitest/code_script-switching-01.js, expected http://example.com/browser/devtools/client/debugger/test/mochitest/code_script-switching-02.js
Blocks: e10s-tests
tracking-e10s: --- → +
James, my comprehension from the race fixes in debugger tests makes me think this test is invalid. We can't assert the exact same source is going to be selected on reload, for the same reason initDebugger is complex: https://dxr.mozilla.org/mozilla-central/source/devtools/client/debugger/test/mochitest/head.js#599-606 let isSelected = Sources.selectedItem.attachment.source.url === source; if (!isSelected) { // Ensure that the source is loaded first before trying to select it yield waitForSourceLoaded(debuggerPanel, source); // Select the js file. let onSource = waitForSourceAndCaret(debuggerPanel, source, line ? line : 1); Sources.selectedValue = getSourceActor(Sources, source); yield onSource; } Link to the test itself: https://dxr.mozilla.org/mozilla-central/source/devtools/client/debugger/test/mochitest/browser_dbg_reload-same-script.js?q=file%3Abrowser_dbg_reload-same-script.js&redirect_type=single The sources are not necessarily loaded in time via the Debugger API when the UI decides to choose the source to display. Or, do we just miss some more SOURCE_SHOWN within reloadPage helper: function reloadPage() { const navigated = waitForNavigation(gPanel); reload(gPanel); return navigated; } ?
Flags: needinfo?(jlong)
You are right, at a glance this test does seem racy. It should have been always racy... not sure why it started in December. I think it would work to wait for 2 NEW_SOURCE notifications in `reloadPage`, that way it would always wait until the new sources are shown. This can be done with `waitForDispatch`. const constants = gDebugger.require("./content/constants"); yield waitForDispatch(gPanel, constants.NEW_SOURCE, 2); I think that should work.
Flags: needinfo?(jlong)
So is it just a race in the test itsef? Where we don't wait enough time before asserting the selected source? So are you saying that the debugger will always end up selecting the previous selected source, *always*? Even when debugger API introduces some delay in listing the sources? I thought it was just that the debugger behavior is not determinist and won't necessarely end up on the previously selected source?? If that's the case, there is nothing we can do to make this test be correct.
(In reply to Alexandre Poirot [:ochameau] from comment #11) > So is it just a race in the test itsef? > Where we don't wait enough time before asserting the selected source? > So are you saying that the debugger will always end up selecting the > previous selected source, *always*? Even when debugger API introduces some > delay in listing the sources? There is a delay in which the debugger selects a source, so I guess it won't always select it. However, for 2 small sources, those should always come in fast enough... but I see what you mean. Basically, it will select a source if it is a "preferred source", but it waits 200ms and checks if a source is not selected, and then selects the first one. So if they are really slow coming in, the expected "preferred source" may not be checked. So the functionality itself is not completely deterministic, but the delay is long enough to where it should be OK. But if this is causing problems, we can disable the test. I don't know what else to do. The new debugger does not have this delay, and will come with a new testing suite, and will land in ~2 months (at least behind a flag). So we're aiming to get rid of all these tests anyway. > > I thought it was just that the debugger behavior is not determinist and > won't necessarely end up on the previously selected source?? If that's the > case, there is nothing we can do to make this test be correct.
Intermittent e10s test failure
Priority: -- → P5
Product: Firefox → DevTools

Test no longer exists.

Status: NEW → RESOLVED
Closed: 7 years ago
tracking-e10s: + → ---
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.