[QA] Investigate logging common JavaScript exceptions

[Joaquin Oltra Hernandez]

onerror and its behavior is brittle and crappy and practically useless with
minified code. Something to read
https://danlimerick.wordpress.com/2014/01/18/how-to-catch-javascript-errors-with-window-onerror-even-on-chrome-and-firefox/

It may be better than nothing, but probably useless or confusing most of
the time.

On Wed, Feb 25, 2015 at 12:28 AM, Chris McMahon <cmcmahon at wikimedia.org>
wrote:

>
> By design, Selenium knows nothing about javascript errors. We don't really
> have any tools to hand to do this sort of thing, the approach that Sam
> talks about makes more sense.
> -Chris
>
> On Tue, Feb 24, 2015 at 3:14 PM, Jon Robson <jrobson at wikimedia.org> wrote:
>
>> I agree that this probably needs something different to EL.
>>
>> I wonder is if the browser tests can log any JavaScript console errors
>> it encounters during test runs somewhere. This would be added
>> protection for us to prevent errors leaking into production. I've
>> cc'ed QA in case they have any ideas about that.
>>
>>
>> On Tue, Feb 24, 2015 at 2:53 AM, Sam Smith <samsmith at wikimedia.org>
>> wrote:
>> > Hey folks,
>> >
>> > The WikiGrok team committed to the "Investigate logging common
>> JavaScript
>> > exceptions" spike [0] and decided that the outcome should be an email
>> thread
>> > (and, presumably, a ticket after we've hashed this out).
>> >
>> > Here goes nothing…
>> >
>> >> We get various errors such as Error: Module not found: toast Error:
>> Module
>> >> not found: toast
>> >> When these occur it would be good to somehow log this to catch
>> dependency
>> >> problems.
>> >> In theory EventLogging should be able to handle this.
>> >
>> >
>> >> 1. Is this a good idea?
>> >
>> >
>> > Logging errors to something that isn't an error log?
>> >
>> > That aside, I don't think logging errors directly to EL is a good idea,
>> > particularly when we don't know the frequency at which they happen.
>> >
>> >> 2. Is it possible?
>> >
>> >
>> > Sure. See GlobalEventHandlers.onerror [1].
>> >
>> >> 3. How would we do it?
>> >
>> >
>> > I would advise against logging events directly. Define an API for
>> reporting
>> > client-side errors that may or may not use EL as a backend, which we can
>> > change as requirements change without affecting clients. Flexibility it
>> > great, but, more importantly, we'd get control: we could throttle the
>> number
>> > of errors being logged to EL if something nasty sneaks into production
>> (or
>> > has already snuck in) and we could deduplicate errors if necessary.
>> >
>> > So: install an onerror event handler, report the error via the API, and,
>> > whenever possible, tell the user that something has gone wrong and that
>> > we've made a note of it.
>> >
>> > –Sam
>> >
>> > [0]
>> >
>> https://trello.com/c/wuMIhyyc/6-spike-investigate-logging-common-javascript-exceptions-2-hours
>> > [1]
>> >
>> https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onerror
>>
>> _______________________________________________
>> QA mailing list
>> QA at lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/qa
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/qa/attachments/20150225/3683ac13/attachment.html>