Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Line-number-less syntax errors on WPT xhr/overridemimetype-blob.html #24948

Open
pshaughn opened this issue Nov 29, 2019 · 2 comments
Open

Line-number-less syntax errors on WPT xhr/overridemimetype-blob.html #24948

pshaughn opened this issue Nov 29, 2019 · 2 comments
Labels
A-content/script Related to the script thread

Comments

@pshaughn
Copy link
Member

This test isn't using iframes, javascript: urls, eval, or anything else that would cause Javascript to be run without associated line numbers, and yet "The string did not match the expected pattern." (the SyntaxError message) appears in the test log with no Javascript trace. This isn't the only test I've seen that gets that error and no trace, but in the ones I saw before, there was more of a reason to think the line number might reasonably be absent.

I don't know how the WPT test harness actually works, so the line number thing could possibly be a tests problem and not a Servo problem. The syntax error happening at all is still a Servo bug if so.

@pshaughn
Copy link
Member Author

xhr/overridemimetype-invalidmimetype.html does it too

@jdm jdm added the A-content/script Related to the script thread label Nov 29, 2019
@jdm jdm added this to To do in web-platform-test failures via automation Nov 29, 2019
@jdm
Copy link
Member

jdm commented Nov 29, 2019

In this particular case, the syntax error is triggered by returning Err::SyntaxError from a fallible DOM method (overrideMimeType), which is automatically converted into a JS exception by the WebIDL code generator:

        let result: Result<(), Error> = this.OverrideMimeType(arg0);
        let result = match result {
            Ok(result) => result,
            Err(e) => {
                throw_dom_exception(cx, &this.global(), e);
                return false;
            },
        };

I checked in a debugger and we don't end up in report_pending_exception, so the lack of meaningful output comes from the test harness catching our exception and failing to extract useful information from it:

var status = e instanceof PreconditionFailedError ? this.PRECONDITION_FAILED : this.FAIL;
var message = String((typeof e === "object" && e !== null) ? e.message : e);
var stack = e.stack ? e.stack : null;

There's code to capture a JS stack already in throw_dom_exception (but disabled by default, since it has big performance implications), but the harness would need to find a stack property on the DOMException interface in its current setup to provide anything useful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-content/script Related to the script thread
Projects
Development

No branches or pull requests

2 participants