ErrorEvent should not hold error strongly
Created attachment 346988 [details] Patch
Created attachment 346989 [details] Patch
Comment on attachment 346989 [details] Patch I don’t fully understand the implications of aerialiing an object that could be changed after its serialized. Or if we are doing the right thing when there are multiple worlds involved. But that’s not specific to this patch, which is applying a pattern we already follow elsewhere.
Title of bug is not exactly right since it does need to hold the error “strongly” in the sense that its a reference that keeps the error object alive, just needs to do it in a way that is garbage collection compatible and doesn’t lead to reference cycles and storage leaks!
Committed r234789: <https://trac.webkit.org/changeset/234789>
<rdar://problem/43210312>
Looks like this revision <https://trac.webkit.org/changeset/234789> has caused build failure on Windows release https://build.webkit.org/builders/Apple%20Win%20Release%20%28Build%29/builds/11156 error stdio: https://build.webkit.org/builders/Apple%20Win%20Release%20%28Build%29/builds/11156/steps/compile-webkit/logs/stdio
Seems highly unlikely this change directly caused that build failure; maybe due to adding a new unified source file? The failure is a link error about export of a symbol affecting units tests. We should get someone to dive deeper into it. A rollout would be OK but this seems really peculiar.