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

Exception reporting muting is not interoperable #10514

Open
domenic opened this issue Jul 25, 2024 · 0 comments
Open

Exception reporting muting is not interoperable #10514

domenic opened this issue Jul 25, 2024 · 0 comments
Labels
interop Implementations are not interoperable with each other topic: error reporting

Comments

@domenic
Copy link
Member

domenic commented Jul 25, 2024

What is the issue with the HTML Standard?

Previously: #958, #2440, #3149.

In some cases, exceptions that have something to do with cross-origin scripts are "muted", i.e. the error events get rewritten to have not much information.

Before #10404, the spec tried to pass around an appropriate script to every instance of exception reporting. There were only a few cases where the correct script was unambiguously passed; many others used "the relevant script" or "the appropriate script". The spec then consulted the script's muted errors flag.

In #10404, we gave up on this, and use the new verbiage

Let script be a script found in an implementation-defined way, or null. This should usually be the running script (most notably during run a classic script).

NOTE: Implementations have not yet settled on interoperable behavior for which script is used to determine whether errors are muted in less common cases.

This issue is about settling that problem.


Some suggestions (e.g. in #2440 or #5051) are to drop almost all muting, with the exception of the exceptions that occur during initial script parsing. Given what a mess we have here, I'm more open to this than I was in 2017. But, I doubt we will end up going that direction, since loosening security in a poorly-understood area is not going to be high priority for anyone. And I expect most work on this issue will be done as a side project, so people will not have the bandwidth to push such things through. So the rest of this issue assumes we're sticking with the goal of generally muting exceptions "coming from" cross-origin scripts, whatever that means.


There are two axes of difficulty here:

  1. What does it mean for the error to "come from" cross-origin scripts. Discussed a bit at Clarify "report an exception" #958 (comment). E.g., if the exception object is constructed in a cross-origin script but thrown in a same-origin script, does it get muted? If a cross-origin script calls a same-origin script, is it muted? What about situations like same -> cross -> same, or cross -> same -> cross?

  2. When do we consider whether to mute at all? Create a 'report an exception' algorithm per #958 #10404 (review) discusses this, by breaking down the possible exception reporting sites into categories from "run a script" (OK, obviously we can figure out whether that script is cross-origin) all the way to "there's definitely no script", e.g. declarative shadow DOM. In between there are a lot of different cases where maybe you can trace the result to a script, and maybe you cannot.

The first step to solving this issue is to write an exhaustive matrix of tests, ideally web platform tests, covering these cases.

#958 (comment) and the following comments also have some specific test cases and discussions that should be looked at during any effort here.

@domenic domenic added interop Implementations are not interoperable with each other topic: error reporting labels Jul 25, 2024
domenic pushed a commit that referenced this issue Jul 30, 2024
This carries out the first portion of the plan in #958 (comment), by creating a new "report an exception" algorithm that replaces the previous "report an error" and "report the exception".

The new algorithm directly includes the error propagation and fallback behavior, and requires callers to supply the global object to be used, rather than magically inferring it. It no longer takes a script, since in most cases the script was not rigorously determined. Follow-up work on determining the correct muting behavior (which the script argument was used for) is tracked in #10514.

All call sites within HTML are updated. #10516 tracks updating call sites in other specifications. In most cases the global used for HTML is now specified rigorously and matching implementations. #10526 and #10527 track the remaining cases with interop issues.

Closes #958, with the rest of the plan there tracked via the issues mentioned above, whatwg/webidl#1423, and the https://github.com/whatwg/html/labels/topic%3A%20error%20reporting label.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
interop Implementations are not interoperable with each other topic: error reporting
Development

No branches or pull requests

1 participant