zulip/static/js/setup.js

74 lines
2.6 KiB
JavaScript
Raw Normal View History

import $ from "jquery";
import * as blueslip from "./blueslip";
import * as loading from "./loading";
import * as util from "./util";
// Miscellaneous early setup.
export let password_change_in_progress = false;
export function set_password_change_in_progress(value) {
password_change_in_progress = value;
}
$(() => {
if (util.is_mobile()) {
dependencies: Remove WebSockets system for sending messages. Zulip has had a small use of WebSockets (specifically, for the code path of sending messages, via the webapp only) since ~2013. We originally added this use of WebSockets in the hope that the latency benefits of doing so would allow us to avoid implementing a markdown local echo; they were not. Further, HTTP/2 may have eliminated the latency difference we hoped to exploit by using WebSockets in any case. While we’d originally imagined using WebSockets for other endpoints, there was never a good justification for moving more components to the WebSockets system. This WebSockets code path had a lot of downsides/complexity, including: * The messy hack involving constructing an emulated request object to hook into doing Django requests. * The `message_senders` queue processor system, which increases RAM needs and must be provisioned independently from the rest of the server). * A duplicate check_send_receive_time Nagios test specific to WebSockets. * The requirement for users to have their firewalls/NATs allow WebSocket connections, and a setting to disable them for networks where WebSockets don’t work. * Dependencies on the SockJS family of libraries, which has at times been poorly maintained, and periodically throws random JavaScript exceptions in our production environments without a deep enough traceback to effectively investigate. * A total of about 1600 lines of our code related to the feature. * Increased load on the Tornado system, especially around a Zulip server restart, and especially for large installations like zulipchat.com, resulting in extra delay before messages can be sent again. As detailed in https://github.com/zulip/zulip/pull/12862#issuecomment-536152397, it appears that removing WebSockets moderately increases the time it takes for the `send_message` API query to return from the server, but does not significantly change the time between when a message is sent and when it is received by clients. We don’t understand the reason for that change (suggesting the possibility of a measurement error), and even if it is a real change, we consider that potential small latency regression to be acceptable. If we later want WebSockets, we’ll likely want to just use Django Channels. Signed-off-by: Anders Kaseorg <anders@zulipchat.com>
2019-07-23 01:43:40 +02:00
// Disable the tutorial; it's ugly on mobile.
page_params.needs_tutorial = false;
}
page_params.page_load_time = Date.now();
// Display loading indicator. This disappears after the first
// get_events completes.
if (!page_params.needs_tutorial) {
loading.make_indicator($("#page_loading_indicator"), {
text: "Loading...",
abs_positioned: true,
});
}
// This is an issue fix where in jQuery v3 the result of outerHeight on a node
// that doesnt exist is now “undefined” rather than “null”, which means it
// will no longer cast to a Number but rather NaN. For this, we create the
// `safeOuterHeight` and `safeOuterWidth` functions to safely return a result
// (or 0).
$.fn.safeOuterHeight = function (...args) {
return this.outerHeight(...args) || 0;
};
$.fn.safeOuterWidth = function (...args) {
return this.outerWidth(...args) || 0;
};
// For some reason, jQuery wants this to be attached to an element.
$(document).ajaxError((event, xhr) => {
if (password_change_in_progress) {
// The backend for handling password change API requests
// will replace the user's session; this results in a
// brief race where any API request will fail with a 401
// error after the old session is deactivated but before
// the new one has been propagated to the browser. So we
// skip our normal HTTP 401 error handling if we're in the
// process of executing a password change.
return;
}
if (xhr.status === 401) {
// We got logged out somehow, perhaps from another window
// changing the user's password, or a session timeout. We
// could display an error message, but jumping right to
// the login page conveys the same information with a
// smoother re-login experience.
window.location.replace(page_params.login_page);
}
});
$.fn.expectOne = function () {
if (blueslip && this.length !== 1) {
blueslip.error("Expected one element in jQuery set, " + this.length + " found");
}
return this;
};
});