Closed Bug 589609 Opened 10 years ago Closed 10 years ago

[SeaMonkey 2.1, mochitest-browser-chrome] browser_NetUtil.js:6 - ReferenceError: Cu is not defined

Categories

(Core :: Networking, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla2.0b7

People

(Reporter: kairo, Assigned: sgautherie)

References

(Blocks 1 open bug, )

Details

(Keywords: intermittent-failure, Whiteboard: [sm-perma])

Attachments

(1 file)

TEST-UNEXPECTED-FAIL | chrome://mochikit/content/browser/netwerk/test/browser/browser_NetUtil.js | Exception thrown at chrome://mochikit/content/browser/netwerk/test/browser/browser_NetUtil.js:6 - ReferenceError: Cu is not defined

I guess that should not be too hard to fix.
Blocks: SmTestFail
Assignee: nobody → sgautherie.bz
Status: NEW → ASSIGNED
Component: Testing Infrastructure → Networking
Product: SeaMonkey → Core
QA Contact: testing-infrastructure → networking
This results in "Passed: 10" :-)
Attachment #469367 - Flags: review?(sdwilsh)
Can Seamonkey maybe fix it's test harness so we don't keep having this same issue crop up?  Clearly, the browser test suite has Cu defined.
We use the same test suite, but this is a browser-chrome test, so it's using globals that happen to exist in Firefox. And Cu happens to be a hard global, since it "knows" which window created it which means you can't share it by e.g. importing it from a module.
(In reply to comment #3)
> We use the same test suite, but this is a browser-chrome test, so it's using
> globals that happen to exist in Firefox. And Cu happens to be a hard global,
> since it "knows" which window created it which means you can't share it by e.g.
> importing it from a module.
Can't you define it for the window that these tests run in?
(In reply to comment #4)
> Can't you define it for the window that these tests run in?

Well, Firefox probably profits from the miracle that places overlay defines it, but the browser window even doesn't. What a mess. :(

I won't comment on doing it on our side or I end up either insulting Firefox doing it or Neil not wanting us to copy "Firefox mess", and I'd rather not do any of those.
(In reply to comment #5)
> I won't comment on doing it on our side or I end up either insulting Firefox
> doing it or Neil not wanting us to copy "Firefox mess", and I'd rather not do
> any of those.
But you'll be happy to be passive aggressive about it in the bug... (not helpful, not constructive, and I really should have to point you at https://bugzilla.mozilla.org/page.cgi?id=etiquette.html)
Why is this even a browser-chrome test in the first place? As far as I can tell, this should be a mochichrome test.
(In reply to comment #7)
> Why is this even a browser-chrome test in the first place? As far as I can
> tell, this should be a mochichrome test.
See bug 581175 comment 5
Could add a few lines to browser-test.js:
+if (Cu === undefined)
+  var Cu = Components.utils;
Comment on attachment 469367 [details] [diff] [review]
(Av1) s/Cu/Components.utils/
[Checkin: Comment 14]

Shawn, its been proposed many times that Cu/Ci/Cc should be global for chrome documents, however trying to manually define it in SeaMonkey chrome is a non-starter with our side.

This test of course runs in the main browser xul, where Firefox has Cu, SeaMonkey does not, and we won't be doing it at this level anytime soon.

The global "Do It" has been suggested to be from the harness the same way that |Components| is inserted into scope, but at the same time allowing overwrites of Cu/Cc/Ci etc. such that it *can* be a hidden use, (i.e. === undefined if tested unless actually defined in scope, however if you were to do (without a test) Cu.foo it will work).

Yes this issue keeps cropping up, but why must tests that are in core Gecko, be forced to rely on a global in Firefox? imo it should not be forced to, and I'd also be happy to point out SeaMonkey running the [Core] test suite has many more times than once found, (and gotten fixed) _actual bugs_ in the code.

Can we please get this landed?
Attachment #469367 - Flags: review+
sdwilsh, ping.
(In reply to comment #8)
> (In reply to comment #7)
> > Why is this even a browser-chrome test in the first place? As far as I can
> > tell, this should be a mochichrome test.
> See bug 581175 comment 5
Bah, so this is Gavin's fault?
Comment on attachment 469367 [details] [diff] [review]
(Av1) s/Cu/Components.utils/
[Checkin: Comment 14]

fine, whatever
Attachment #469367 - Flags: review?(sdwilsh) → review+
Comment on attachment 469367 [details] [diff] [review]
(Av1) s/Cu/Components.utils/
[Checkin: Comment 14]

http://hg.mozilla.org/mozilla-central/rev/a654e877432a
Attachment #469367 - Attachment description: (Av1) s/Cu/Components.utils/ → (Av1) s/Cu/Components.utils/ [Checkin: Comment 14]
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b6
V.Fixed, per
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1283973900.1283976331.11919.gz
Linux comm-central-trunk debug test mochitest-other on 2010/09/08 12:25:00
Status: RESOLVED → VERIFIED
Whiteboard: [sm-perma][orange] → [sm-perma]
You need to log in before you can comment on or make changes to this bug.