This is the third most prevalent dom warning during testing. > 1851 [NNNNN] WARNING: 'NS_FAILED(rv)', file dom/fetch/FetchDriver.cpp, line 452 This warning [1] shows up in the following test suites: > mozilla-central_ubuntu64_vm-debug_test-mochitest-e10s-5-bm114-tests1-linux64-build1.txt:693 > mozilla-central_ubuntu64_vm-debug_test-mochitest-5-bm116-tests1-linux64-build1.txt:693 > mozilla-central_ubuntu64_vm-debug_test-web-platform-tests-e10s-3-bm120-tests1-linux64-build5.txt:176 > mozilla-central_ubuntu64_vm-debug_test-web-platform-tests-3-bm117-tests1-linux64-build0.txt:139 > mozilla-central_ubuntu64_vm-debug_test-web-platform-tests-e10s-8-bm125-tests1-linux64-build0.txt:56 > mozilla-central_ubuntu64_vm-debug_test-web-platform-tests-8-bm67-tests1-linux64-build0.txt:56 > mozilla-central_ubuntu64_vm-debug_test-mochitest-e10s-6-bm118-tests1-linux64-build0.txt:10 > mozilla-central_ubuntu64_vm-debug_test-mochitest-6-bm54-tests1-linux64-build0.txt:10 > mozilla-central_ubuntu64_vm-debug_test-mochitest-e10s-4-bm116-tests1-linux64-build1.txt:4 > mozilla-central_ubuntu64_vm-debug_test-mochitest-4-bm116-tests1-linux64-build3.txt:4 > mozilla-central_ubuntu64_vm-debug_test-mochitest-push-bm67-tests1-linux64-build0.txt:3 > mozilla-central_ubuntu64_vm-debug_test-mochitest-e10s-browser-chrome-1-bm67-tests1-linux64-build0.txt:2 > mozilla-central_ubuntu64_vm-debug_test-mochitest-browser-chrome-3-bm121-tests1-linux64-build2.txt:2 > mozilla-central_ubuntu64_vm-debug_test-mochitest-other-bm67-tests1-linux64-build1.txt:1 > mozilla-central_ubuntu64_vm-debug_test-mochitest-e10s-browser-chrome-7-bm122-tests1-linux64-build1.txt:1 > mozilla-central_ubuntu64_vm-debug_test-mochitest-browser-chrome-7-bm123-tests1-linux64-build1.txt:1 It shows up in 34 tests. A few of the most prevalent: > 630 - dom/tests/mochitest/fetch/test_fetch_cors_sw_reroute.html > 378 - dom/tests/mochitest/fetch/test_fetch_cors_sw_empty_reroute.html > 350 - dom/tests/mochitest/fetch/test_fetch_cors.html > 120 - /fetch/api/cors/cors-redirect-credentials.html > 100 - /_mozilla/service-workers/service-worker/fetch-event-redirect.https.html > 43 - /fetch/api/cors/cors-preflight-status.html > 28 - dom/tests/mochitest/fetch/test_formdataparsing.html > 25 - /fetch/api/cors/cors-origin.html > 20 - /fetch/api/redirect/redirect-location-worker.html > 20 - /fetch/api/redirect/redirect-location.html [1] https://hg.mozilla.org/mozilla-central/annotate/c59c022943f6/dom/fetch/FetchDriver.cpp#l452

So, these tests are validating how we handle failures. We can remove this NS_WARN_IF(), but it will make debugging real fetch channel failures more difficult.

How does the debuggability of fetch channel failures compare with the intent of bug 765224?

(In reply to Andrew Overholt [:overholt] from comment #2) > How does the debuggability of fetch channel failures compare with the intent > of bug 765224? My experience is that overly verbose warnings are ignored, are one of the reasons devs do not work with debug builds, and obscure more critical warnings. If the main use case is for debugging fetch I would recommend adding a fetch logger that fetch developers can enable as desired via |NSPR_LOG_MODULES=fetch:5 firefox|. This would allow detecting issues in both debug and release builds as well. You can also enable it at runtime by setting a pref (logging.fetch = 5). If you truly want debug only warnings with this level of verbosity I would recommend doing something like what layout has done [1]. [1] https://dxr.mozilla.org/mozilla-central/rev/4ea7408b3eef059aa248f4b00328f8fdb4475112/layout/base/LayoutLogging.h

FWIW, if Eric wants to write a patch to remove this particular NS_WARN_IF() I would r+.

https://hg.mozilla.org/integration/mozilla-inbound/rev/ce018c5ee5c15e76c640f0c0e2414ab7c6a04657 Bug 1253054 - Stop warning if request has already failed. r=bkelly