Consider removing ErrorReportBuilder::WithSideEffects
Categories
(Core :: JavaScript Engine, task, P3)
Tracking
()
People
(Reporter: evilpies, Unassigned)
References
(Blocks 1 open bug)
Details
Like bug 1746186 has shown ErrorReportBuilder::WithSideEffects makes it quite easy to accidentally invoke user JS code in unexpected places. We should consider if we can remove this.
It's quite likely that the sniffing code is still hit quite often when handling cross-compartment wrappers or other weird constructs that can happen when running Firefox. I think this would also change window.onerror in certain cases.
At least the normal web console should not be effect, because that is just using the error object directly instead of the message produced by ErrorReportBuilder.
|
||
Updated•3 years ago
|
|
|
||
Comment 1•1 year ago
|
||
A general question about this bug: Does this end up changing web-observable behaviours (I think the answer is yes); I'm trying to figure out if this is the right component for this, or if really this needs to be a bug tree about individual consumers, and each needing to write wpt tests before we can really do this.
A general question about this bug: Does this end up changing web-observable behaviours (I think the answer is yes)
Yes it does. Hopefully it doesn't really matter, because it (usually) only happens for uncaught errors. There are quite a few uses of this function, but I think AutoJSAPI::ReportException is probably the most critical, considering it is the main DOM main-thread error reporting path.
Before we consider fixing this, we should make sure NoSideEffects can handle most of the common error scenarios correctly, e.g. I think we had issues with wrapped exceptions at some point? Also bonus points for making sure that we have the WebConsole based error reporting for all of these cases.
Description
•