I'd rather get an Error-like duck-typed object with this shell info for cross-domain requests than to not get a real Error object when the unhandled error *is* from the same origin.
Adding the trace as another new argument to `window.onerror` is certainly an option but the parameter list is getting long and I suspect that Error prototypes may still gain additional properties in the future. Continuing down this path of adding more parameters rather than just passing an Error instance or Error-like object (or providing a separate supplemental method like `window.getLastError()` seems like one of those decisions that might results in infinite sadness in the future. Sincerely, James Greene On Mon, Mar 11, 2013 at 5:50 AM, Simon Pieters <sim...@opera.com> wrote: > On Tue, 05 Feb 2013 08:20:27 +0100, Elliott Sprehn <espr...@chromium.org> > wrote: > > On Mon, Feb 4, 2013 at 5:44 PM, Oliver Hunt <oli...@apple.com> wrote: >> >> ... >>> That's tricky - what is your "stack trace"? You can very easily end up >>> leaking private information across frames. >>> >>> >>> window.onerror is triggered across non-same origin frames? >> > > Yes, but always with these arguments: > > "Script error.", "", 0, 0 > > -- > Simon Pieters > Opera Software >