Chrome generates these to report things like “ResizeObserver loop
limit exceeded” (which is harmless).
Signed-off-by: Anders Kaseorg <anders@zulipchat.com>
Not all our errors actually happen in the contexts we were
wrapping (e.g. `setTimeout` and `_.throttle`). Also this fixes the
neat Firefox inspector feature that shows you where your event
handlers for a given DOM element actually live.
Using this "semi-modern" browser event means that Safari 9 and older
and IE10 and older may not have our browser error reporting active;
that seems fine giving the vanishing market share of those browsers.
https://blog.sentry.io/2016/01/04/client-javascript-reporting-window-onerror
Signed-off-by: Anders Kaseorg <anders@zulipchat.com>
This commit prepares the frontend code to be consumed by webpack.
It is a hack: In theory, modules should be declaring and importing the
modules they depend on and the globals they expose directly.
However, that requires significant per-module work, which we don't
really want to block moving our toolchain to webpack on.
So we expose the modules by setting window.varName = varName; as
needed in the js files.
This commit improves the output that blueslip produces while
showing error stack traces on the front-end. This is done by
using a library called error-stack-parser to format the stack
traces.
This commit also edits the webpack config to use a different
devtool setting since the previous one did not support sourcemaps
within stack traces. It also removes a plugin that was obviated
by this change.
Also adds a custom rule to eslint. Since the recommended way of extending
eslint is to create plugins as standalone npm packages, the separate rule
is published as 'eslint-plugins-empty-returns'.
Fixes#8669.
This now shows `blueslip.error` and other JS exceptions in development
in the alert box at the top of the page. Hopefully this will make it
a lot easier to notice newly introduced JS exceptions when working on
Zulip.
Tweaked by tabbott to handle all JS errors, not just blueslip.error.
Fixes: #6155.
When in debug mode, previously an explicit `blueslip.error()` call
would not display the original stack trace of the error, making
debugging difficult.
This isn't perfect, in that it seems to display some tracebacks
multiple times, but at least the trace is available.
In a few cases the $.each was doing something imperatively that was
terser and easier to understand by using a different Underscore method,
so a few of these I rewrote.
Some code was using the fact that jQuery sets `this` in the callback to
be the item; I rewrote those to use an explicit parameter.
Some code was using $(some selector).each(callback). I converted these
to _.each($(some selector), callback).
One function, ui.process_condensing, was written to be a jQuery $.each
callback despite being in a totally different module from code using it.
I noticed this and updated the function's args.
(imported from commit bf5922a35f257c168cc09ec1d077415d6ef19a03)
Anders Kaseorg
Steve Howell
Armaan Ahluwalia
Rohitt Vashishtha
Tim Abbott
Alena Volkova
derAnfaenger
Brock Whittaker
Joshua Pan
Steve Howell
Arpith Siromoney
Tim Abbott
Jason Michalski
Zev Benjamin
Tim Abbott
Scott Feeney
Tim Abbott