- From: James Greene <james.m.greene@gmail.com>
- Date: Fri, 12 Jul 2013 13:30:43 -0500
- To: Simon Pieters <simonp@opera.com>
- Cc: Oliver Hunt <oliver@apple.com>, whatwg@lists.whatwg.org, Elliott Sprehn <esprehn@chromium.org>, Garrett Smith <dhtmlkitchen@gmail.com>, nathan.f77@gmail.com
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 <simonp@opera.com> wrote:
> On Tue, 05 Feb 2013 08:20:27 +0100, Elliott Sprehn <esprehn@chromium.org>
> wrote:
>
> On Mon, Feb 4, 2013 at 5:44 PM, Oliver Hunt <oliver@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
>
Received on Friday, 12 July 2013 18:31:28 UTC