mochitest and the error console
Zachary Weinberg
I've attached the test case. What am I doing wrong? Yes, I did the netscape.security.PrivilegeManager.enablePrivilege('UniversalXPConnect'); dance.
Thanks,
zw
L. David Baron
> I've attached the test case. What am I doing wrong? Yes, I did
> the
> netscape.security.PrivilegeManager.enablePrivilege('UniversalXPConnect');
> dance.
Perhaps not enough? Its effects have function-scope, so you
probably need to do it within the listener as well.
-David
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/
Boris Zbarsky
> I've attached the test case. What am I doing wrong?
I think David's right: you need expanded privs in observe().
That said, I have two other questions:
1) Why not use an onload attribute on the <iframe> instead of resetting
the load handler on the contentWindow a bunch of times?
2) I assume observe() will at some point fail out if it's called?
-Boris
Zachary Weinberg
> Zachary Weinberg wrote:
> > I've attached the test case. What am I doing wrong?
>
> I think David's right: you need expanded privs in observe().
That was indeed the problem. (I was assuming the privilege expansion was effective for the rest of the script, or perhaps that once you had a console object you didn't need privileges to *use* it.)
> 1) Why not use an onload attribute on the <iframe> instead of
> resetting the load handler on the contentWindow a bunch of times?
Well, I cribbed a lot of this code from another test in layout/style, and that's what it did, but to be honest I'm not sure how to write the equivalent using an onload attribute, or why that'd be better.
> 2) I assume observe() will at some point fail out if it's called?
The test is for error recovery, so it's not sensible for there to be *no* syntax errors reported. Instead what I was going to do is make all the diagnostics that should appear for this general class of syntax error (unexpected EOF) conform to one regular expression, and have observe() fail the test if it sees anything else. But I haven't coded any of that yet; I wanted to make sure I *could* get at the error console first.
zw
L. David Baron
> > 2) I assume observe() will at some point fail out if it's called?
>
> be *no* syntax errors reported. Instead what I was going to do is
> make all the diagnostics that should appear for this general class
> of syntax error (unexpected EOF) conform to one regular
> expression, and have observe() fail the test if it sees anything
> else. But I haven't coded any of that yet; I wanted to make sure
> I *could* get at the error console first.
This sounds like you'd end up with a test that would fail in
localized versions of the browser, which sounds bad, unless you
pulled the strings for the current locale out of the properties
file.
I'm also a bit hesitant as to whether we should test error
*reporting* that heavily, particularly because I'd really like our
tests to be things that we really think ought to pass for the
indefinite future, not things that are going to have to be adjusted
if we start reporting additional errors or warnings or improving the
descriptions of our existing ones.
I'd think it's more important to test the effects of parsing on the
behavior of a Web page. (It might help this to implement
CSSStyleRuleImpl::SetSelectorText so that we support setting of
.selectorText on rules.)
Zachary Weinberg
> On Friday 2008-05-16 15:47 -0700, Zachary Weinberg wrote:
> > The test is for error recovery, so it's not sensible for there to
> > be *no* syntax errors reported. Instead what I was going to do is
> > make all the diagnostics that should appear for this general class
> > of syntax error (unexpected EOF) conform to one regular
> > expression, and have observe() fail the test if it sees anything
> > else.
>
> localized versions of the browser, which sounds bad, unless you
> pulled the strings for the current locale out of the properties
> file.
>
> I'm also a bit hesitant as to whether we should test error
> *reporting* that heavily, particularly because I'd really like our
> tests to be things that we really think ought to pass for the
> indefinite future, not things that are going to have to be adjusted
> if we start reporting additional errors or warnings or improving the
> descriptions of our existing ones.
>
> I'd think it's more important to test the effects of parsing on the
> behavior of a Web page. (It might help this to implement
> CSSStyleRuleImpl::SetSelectorText so that we support setting of
> .selectorText on rules.)
I hear you and I largely agree, but I'm really at a loss for an alternative for e.g.
<style>@charset "utf-8</style>
since, whether or not the @-rule is honored, it applies only to the contents of that <style> block, so it can't affect the rendering! Many of Mats Palmgren's tests in bug 325064 are like that.
(Maybe the answer is that if it can't affect the rendering, it doesn't honestly matter if we obey the letter of the spec...)
zw
Boris Zbarsky
> I hear you and I largely agree, but I'm really at a loss for an alternative for e.g.
>
> <style>@charset "utf-8</style>
For this, you could examine document.styleSheets[n].cssRules[0] or
document.styleSheets[n].cssRules[0].cssText or both, depending on what you're
trying to test.
That won't tell you whether the rule is "honored", but at least whether it's parsed.
-Boris
Boris Zbarsky
> Well, I cribbed a lot of this code from another test in layout/style, and
> that's what it did, but to be honest I'm not sure how to write the equivalent
> using an onload attribute, or why that'd be better.
<iframe onload="doSomething()"></iframe>
doSomething() will be called every time a new document is loaded in the iframe.
It's better only insofar as you don't have to keep resetting the handler and
don't have to worry about timing issues, async vs sync loading, window
lifetimes, when window scope clearing, etc.
Basically, it's safer and simpler to use than setting a handler on the window in
the iframe.
-Boris
Zachary Weinberg
Is that equivalent to setting the .onload property on the *frame* (rather than its window) from JS? I would rather keep all the logic in the script if possible. (I changed my script to set .onload on the frame, once, and it seems to work, but I'm quite the n00b when it comes to client scripting.)
zw
Boris Zbarsky
> Is that equivalent to setting the .onload property on the *frame* (rather than its window) from JS? I would rather keep all the logic in the script if possible. (I changed my script to set .onload on the frame, once, and it seems to work, but I'm quite the n00b when it comes to client scripting.)
That should be equivalent, yes.
Here's a simple testcase for the whole thing:
data:text/html,<body><iframe src="data:text/html,<a
href='data:text/plain,test'>Click
me</a>"></iframe><script>document.getElementsByTagName("iframe")[0].onload=function()
{ alert('loaded ' + this.contentWindow.location.href); };</script>
Ray Kiddy
It might be simpler to create a test that takes the log of some test
runs and greps through that log for certain strings at certain places.
If you are trying to verify something is in the stdout, why not just
test the text actually written out. This would seem to be simpler.
cheers - ray