You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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?
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.
The text was updated successfully, but these errors were encountered:
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.
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
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:
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?
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.
The text was updated successfully, but these errors were encountered: