This commit was originally automatically generated using `tools/lint
--only=eslint --fix`. It was then modified by tabbott to contain only
changes to a set of files that are unlikely to result in significant
merge conflicts with any open pull request, excluding about 20 files.
His plan is to merge the remaining changes with more precise care,
potentially involving merging parts of conflicting pull requests
before running the `eslint --fix` operation.
Signed-off-by: Anders Kaseorg <anders@zulipchat.com>
With webpack, variables declared in each file are already file-local
(Global variables need to be explicitly exported), so these IIFEs are
no longer needed.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Apparently, we didn't have one of these, and thus had a moderate
number of generally very old violations in the codebase. Fix this and
clear the ones that exist..
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 is preparation for enabling an eslint indentation configuration.
90% of these changes are just fixes for indentation errors that have
snuck into the codebase over the years; the others are more
significant reformatting to make eslint happy (that are not otherwise
actually improvements).
The one area that we do not attempt to work on here is the
"switch/case" indentation.
We had code that would try to re-render locally echoed messages
that were rendered right before a browser restart. This code
has gotten buggy over time, so we are removing it for now.
We will try to re-solve the problem as part of #5825, but
possibly with a different strategy.
This reverts commit 7bf10ec74f.
Apparently, SockJS 1.1.1 is broken with the browser used in our legacy
desktop app, resulting in messages being silently not sent.
This speeds up CasperJS tests by 25 seconds per main app page load.
When we switched the SockJS, the casper tests got inexplicably slower. I
finially figured out what's going on. The first SockJS XHR request (remember
that we don't get websockets in the test suite) gets considered part of the page
load and therefore the PhantomJS onLoadFinished handler doesn't get called until
the SockJS XHR finishes, which happens at the heartbeat, 25 seconds later. To
fix this, we simply don't create the SockJS object on page load since it will be
created on demand, anyway.
(imported from commit 845a97526c5102df426cd6fc26182a734e7fcab6)
We've only gotten one error report for this error, and it didn't have a stack
trace, so it's hard to know whether this will actually fix the issue or not.
(imported from commit 7bff052347a33f67d8479b1cb23f6e5e24defc75)
Without an explicit close, we will continue to get messages on the old
connection, even once we replace the _sockjs property. This leads to
"impossible" situations, such as receiving ACKs after reconnecting.
(imported from commit f8927fdf0551610e5b9d1db29bba00e160e76b6d)
There will be browser errors on staging when this is deployed due to the socket
protocol changing.
(imported from commit f1eda5b5c2ec9c60c23b3ca96277a61debadf5bb)
This will hopefully help with the send dialog being stuck on
"sending" as well as allowing us to not show errors to the user on
reconnect.
(imported from commit 31ee889853f348e486863073dc130cdfb4e1338d)
Anders Kaseorg
Tim Abbott
Armaan Ahluwalia
Shubham Dhama
Steve Howell
fionabunny
Rafid Aslam
K.Kanakhin
AZtheAsian
kevv87
Zev Benjamin
Leo Franchi
Tim Abbott