2020-02-13 22:34:29 +01:00
|
|
|
|
const util = require("./util");
|
2012-10-03 22:07:04 +02:00
|
|
|
|
// Miscellaneous early setup.
|
|
|
|
|
|
|
|
|
|
$(function () {
|
2017-03-09 02:34:45 +01:00
|
|
|
|
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.
|
2017-05-11 20:01:56 +02:00
|
|
|
|
page_params.needs_tutorial = false;
|
2017-03-09 02:34:45 +01:00
|
|
|
|
}
|
|
|
|
|
|
2017-03-23 07:05:36 +01:00
|
|
|
|
page_params.page_load_time = new Date().getTime();
|
|
|
|
|
|
2012-10-03 22:07:04 +02:00
|
|
|
|
// Display loading indicator. This disappears after the first
|
2014-01-30 20:29:00 +01:00
|
|
|
|
// get_events completes.
|
2020-02-19 21:59:26 +01:00
|
|
|
|
if (!page_params.needs_tutorial) {
|
2017-04-05 03:55:28 +02:00
|
|
|
|
loading.make_indicator($('#page_loading_indicator'), {text: 'Loading...', abs_positioned: true});
|
2012-10-03 23:22:51 +02:00
|
|
|
|
}
|
2017-07-27 21:40:26 +02:00
|
|
|
|
|
|
|
|
|
// This is an issue fix where in jQuery v3 the result of outerHeight on a node
|
|
|
|
|
// that doesn’t 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).
|
2020-02-12 01:35:16 +01:00
|
|
|
|
$.fn.safeOuterHeight = function (...args) {
|
|
|
|
|
return this.outerHeight(...args) || 0;
|
2017-07-27 21:40:26 +02:00
|
|
|
|
};
|
|
|
|
|
|
2020-02-12 01:35:16 +01:00
|
|
|
|
$.fn.safeOuterWidth = function (...args) {
|
|
|
|
|
return this.outerWidth(...args) || 0;
|
2017-07-27 21:40:26 +02:00
|
|
|
|
};
|
|
|
|
|
|
2012-11-21 00:16:09 +01:00
|
|
|
|
// For some reason, jQuery wants this to be attached to an element.
|
2016-08-24 22:11:37 +02:00
|
|
|
|
$(document).ajaxError(function (event, xhr) {
|
2012-11-21 00:16:09 +01:00
|
|
|
|
if (xhr.status === 401) {
|
|
|
|
|
// We got logged out somehow, perhaps from another window or a session timeout.
|
|
|
|
|
// We could display an error message, but jumping right to the login page seems
|
|
|
|
|
// smoother and conveys the same information.
|
2013-11-13 21:31:09 +01:00
|
|
|
|
window.location.replace(page_params.login_page);
|
2012-11-21 00:16:09 +01:00
|
|
|
|
}
|
|
|
|
|
});
|
2013-04-04 00:55:36 +02:00
|
|
|
|
|
2014-03-13 16:06:14 +01:00
|
|
|
|
if (typeof $ !== 'undefined') {
|
|
|
|
|
$.fn.expectOne = function () {
|
|
|
|
|
if (blueslip && this.length !== 1) {
|
|
|
|
|
blueslip.error("Expected one element in jQuery set, " + this.length + " found");
|
|
|
|
|
}
|
|
|
|
|
return this;
|
|
|
|
|
};
|
2017-03-01 01:31:33 +01:00
|
|
|
|
|
|
|
|
|
$.fn.within = function (sel) {
|
2018-06-06 18:19:09 +02:00
|
|
|
|
return $(this).is(sel) || $(this).closest(sel).length;
|
2017-03-01 01:31:33 +01:00
|
|
|
|
};
|
2014-03-13 16:06:14 +01:00
|
|
|
|
}
|
2012-10-03 22:07:04 +02:00
|
|
|
|
});
|