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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 >> [email protected] >> https://lists.wikimedia.org/mailman/listinfo/qa >> > >
_______________________________________________ QA mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/qa
