[QA] Investigate logging common JavaScript exceptions

Chris McMahon cmcmahon at wikimedia.org
Tue Feb 24 23:28:25 UTC 2015


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/20150224/48af46f1/attachment.html>


More information about the QA mailing list