Closed Bug 853568 Opened 12 years ago Closed 12 years ago

Intermittent browser_webconsole_bug_599725_response_headers.js | we do not have the Content-Type header | Content-Length != 60 - Didn't expect 60, but got it

Categories

(DevTools :: Console, defect)

Product:
DevTools
Component:
Console
Platform:
x86_64
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Firefox 23

People

(Reporter: emorley, Assigned: msucan)

References

Details

(Keywords: intermittent-failure)

Attachments

(2 files, 1 obsolete file)

debug output in case of failure
2.20 KB, patch
Details | Diff | Splinter Review
another try for fixing the issue
2.89 KB, patch
vporof
: review+
Details | Diff | Splinter Review
Rev5 MacOSX Mountain Lion 10.8 mozilla-central opt test mochitest-browser-chrome on 2013-03-21 10:47:10 PDT for push a73a2b5c423b slave: talos-mtnlion-r5-049 https://tbpl.mozilla.org/php/getParsedLog.php?id=20937260&tree=Firefox { 11:01:57 INFO - TEST-START | chrome://mochitests/content/browser/browser/devtools/webconsole/test/browser_webconsole_bug_599725_response_headers.js 11:01:57 INFO - TEST-INFO | chrome://mochitests/content/browser/browser/devtools/webconsole/test/browser_webconsole_bug_599725_response_headers.js | Console message: [JavaScript Error: "The character encoding of the HTML document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the page must be declared in the document or in the transfer protocol." {file: "http://example.com/browser/browser/devtools/webconsole/test/test-bug-599725-response-headers.sjs" line: 0}] 11:01:57 INFO - MOZ_EVENT_TRACE sample 1363888917691 122 11:01:57 INFO - TEST-INFO | chrome://mochitests/content/browser/browser/devtools/webconsole/test/browser_webconsole_bug_599725_response_headers.js | Console message: [JavaScript Error: "The character encoding of the HTML document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the page must be declared in the document or in the transfer protocol." {file: "http://example.com/browser/browser/devtools/webconsole/test/test-bug-599725-response-headers.sjs" line: 0}] 11:01:57 INFO - TEST-PASS | chrome://mochitests/content/browser/browser/devtools/webconsole/test/browser_webconsole_bug_599725_response_headers.js | page load was logged 11:01:57 INFO - TEST-PASS | chrome://mochitests/content/browser/browser/devtools/webconsole/test/browser_webconsole_bug_599725_response_headers.js | we have the response headers 11:01:57 WARNING - TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/devtools/webconsole/test/browser_webconsole_bug_599725_response_headers.js | we do not have the Content-Type header 11:01:57 INFO - Stack trace: 11:01:57 INFO - JS frame :: chrome://mochitests/content/browser/browser/devtools/webconsole/test/browser_webconsole_bug_599725_response_headers.js :: <TOP_LEVEL> :: line 33 11:01:57 INFO - JS frame :: resource://gre/modules/devtools/dbg-client.jsm :: <TOP_LEVEL> :: line 513 11:01:57 INFO - JS frame :: resource://gre/modules/commonjs/sdk/core/promise.js :: resolve :: line 120 11:01:57 INFO - JS frame :: resource://gre/modules/commonjs/sdk/core/promise.js :: then :: line 45 11:01:57 INFO - JS frame :: resource://gre/modules/commonjs/sdk/core/promise.js :: then :: line 155 11:01:57 INFO - JS frame :: resource://gre/modules/devtools/dbg-client.jsm :: DC_onPacket :: line 521 11:01:57 INFO - JS frame :: chrome://global/content/devtools/dbg-transport.js :: <TOP_LEVEL> :: line 224 11:01:57 INFO - native frame :: <unknown filename> :: <TOP_LEVEL> :: line 0 11:01:57 WARNING - TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/devtools/webconsole/test/browser_webconsole_bug_599725_response_headers.js | Content-Length != 60 - Didn't expect 60, but got it 11:01:57 INFO - Stack trace: 11:01:57 INFO - JS frame :: chrome://mochikit/content/browser-test.js :: test_isnot :: line 506 11:01:57 INFO - JS frame :: chrome://mochitests/content/browser/browser/devtools/webconsole/test/browser_webconsole_bug_599725_response_headers.js :: <TOP_LEVEL> :: line 34 11:01:57 INFO - JS frame :: resource://gre/modules/devtools/dbg-client.jsm :: <TOP_LEVEL> :: line 513 11:01:57 INFO - JS frame :: resource://gre/modules/commonjs/sdk/core/promise.js :: resolve :: line 120 11:01:57 INFO - JS frame :: resource://gre/modules/commonjs/sdk/core/promise.js :: then :: line 45 11:01:57 INFO - JS frame :: resource://gre/modules/commonjs/sdk/core/promise.js :: then :: line 155 11:01:57 INFO - JS frame :: resource://gre/modules/devtools/dbg-client.jsm :: DC_onPacket :: line 521 11:01:57 INFO - JS frame :: chrome://global/content/devtools/dbg-transport.js :: <TOP_LEVEL> :: line 224 11:01:57 INFO - native frame :: <unknown filename> :: <TOP_LEVEL> :: line 0 11:01:57 INFO - MOZ_EVENT_TRACE sample 1363888917909 217 11:01:57 INFO - INFO TEST-END | chrome://mochitests/content/browser/browser/devtools/webconsole/test/browser_webconsole_bug_599725_response_headers.js | finished in 323ms }
Attached patch proposed patch (obsolete) — — Splinter Review
This is rather simplistic in its approach. Content-Length cannot be different, unless the previous page load happens to be logged instead. What I'm doing here is delaying the webconsole open, in the hope we avoid that case. Try push is green https://tbpl.mozilla.org/?tree=Try&rev=d963ad439d88 Any ideas?
Assignee: nobody → mihai.sucan
Status: NEW → ASSIGNED
Attachment #732762 - Flags: review?(vporof)
Comment on attachment 732762 [details] [diff] [review] proposed patch Review of attachment 732762 [details] [diff] [review]: ----------------------------------------------------------------- ::: browser/devtools/webconsole/test/browser_webconsole_bug_599725_response_headers.js @@ +43,5 @@ > addTab(TEST_URI); > > browser.addEventListener("load", function onLoad() { > browser.removeEventListener("load", onLoad, true); > + executeSoon(() => openConsole(null, () => { There's no harm in doing this, but I'm generally skeptical of using executeSoon() to fix oranges. If you're sure adding it here, an explanatory comment would certainly help.
Attachment #732762 - Flags: review?(vporof) → review+
(In reply to Victor Porof [:vp] from comment #9) > Comment on attachment 732762 [details] [diff] [review] > proposed patch > > Review of attachment 732762 [details] [diff] [review]: > ----------------------------------------------------------------- > > ::: > browser/devtools/webconsole/test/ > browser_webconsole_bug_599725_response_headers.js > @@ +43,5 @@ > > addTab(TEST_URI); > > > > browser.addEventListener("load", function onLoad() { > > browser.removeEventListener("load", onLoad, true); > > + executeSoon(() => openConsole(null, () => { > > There's no harm in doing this, but I'm generally skeptical of using > executeSoon() to fix oranges. If you're sure adding it here, an explanatory > comment would certainly help. Not much of a comment to add, really. Our tests are filled with "hopeful" executeSoon() calls, unfortunately. As for being sure: given we do not have enough debug information as to why this failure happens, I cannot be sure this is the way to fix the problem. Given it's a new intermittent failure, I expect it's caused by subtle changes somewhere else in Gecko. Welcome to the world of web console tests. :) Things have actually improved since the early days of the web console. Prompted by these concerns I'm updating the patch to show debug information in case the test fails. That should allow us to do a better fix if we still see more failures. Thanks for the reviews!
Attachment #732762 - Attachment is obsolete: true
https://hg.mozilla.org/mozilla-central/rev/3bcc3a681fcb
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → Firefox 23
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Debug info logged by the test confirms my worry: the network event we get is the first load, not the second reload, hence the test failure. I'm going to look into a better way to guard against that problem. It is surprising we started receiving the page "load" event *before* the page load network request completes...
Instead of trying to avoid logging the first load, let's try taking it in entirely: open the web console before the first load, wait for both loads, then check the headers. Try push: https://tbpl.mozilla.org/?tree=Try&rev=63571056644d
Attachment #732827 - Attachment is obsolete: true
Attachment #733392 - Flags: review?(vporof)
Comment on attachment 732827 [details] [diff] [review] debug output in case of failure (shouldn't have marked this one as obsolete... bad habit!)
Attachment #732827 - Attachment is obsolete: false
Comment on attachment 733392 [details] [diff] [review] another try for fixing the issue Review of attachment 733392 [details] [diff] [review]: ----------------------------------------------------------------- Ok!
Attachment #733392 - Flags: review?(vporof) → review+
https://hg.mozilla.org/mozilla-central/rev/7bf86554e74a
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → FIXED
Depends on: 873729
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: