Also switches the default behaviour of the code to not translate the
emoticons. Earlier, the code was testing-aware, and used to translate
when there was no user profile data available(assuming that as a testing
environment).
The main testing of the translate emoticons code is in the
node_tests/emoji.js file. This code just checks if the setting
to enable/disable the emoticon translation is being honored.
Earlier, we used to convert all occurrences of an emoticon on the
frontend. That behavior has been altered to do conversions only
when the emoticon has some terminal symbols around them, and not
any alphabet or number. Also adds tests for emoji conversions for
the above logic.
Fixes#8585.
With this we have the same way to save changes done in org profile
subsection, i.e. show "Save" button beside header of subsection,
add "Discard changes" button for org profile subsection and
show "Save" and "Discard" button only when needed.
Also, there is so much code which become obsolete which is removed
in this commit.
Based on extensive manual testing with print-debugg (the exact
situation here was highly reproducible), in the absence of this line
here or slightly above here, Chrome 64 will consistently trigger an
extra scroll-forward-by-12000-pixels size downward scrolling event
immediately after it finishes rendering the 5th batch of ~100 messages
one gets from hitting the End key in `near:1` narrows.
I don't understand clearly why this change would protect against such
a Chrome bug, but my best guess is that Chrome was doing some sort of
incorrect optimization, and querying the scrollTop was forcing it to
come to a clear conclusion about the scrolling position before
appending more content.
But runs with the scrollTop() line not present in that function show a
scrollTop of around 25K in `append()` just before the call to
`render()`, and 37K at the end; while runs with this scrollTop line
always show 25K both before and after, so it does seem to work.
This number is way too high, because of a recent regression. Adding a
test here lets us prevent similar regressions in the future and
provides an easy way to be sure if we've fixed the issue.
Previously, when unnarrowing, we were calling this on the wrong
selector (this was missed years ago when we refactored Zulip to use
divs rather than table rows in the main message feed).
Noticed while debugging #5312.
Previously, if you started out with a very small window, loaded the
Zulip webapp, and then resized the window to be larger, you'd get the
condensed "[More]" links on essentially every message. This failure
mode was most visible with multi-protocol Electron apps like Rambox
that would sloppily start with a tiny window and then resize it when
loading Zulip.
The Rambox experience was essential to our being able to track this
down; once we knew what was happening, the fix was simply to
re-compute the condense state on resize.
Commit message rewritten by tabbott to explain the debugging and
context involved here, since this was one of our longest-lived mystery
bugs.
Fixes#5312.
This is apparently installed by the perl package; I hadn't even known
it existed. We of course want to use the sha1sum command from
coreutils.
Fixes#8836.
This commit is similar to the prior commit, in that we are
more disciplined about setting up handlers. We set them up right
as the widgets get rendered, and the handlers only delegate
up to the container div (id="stream_creation").
We now wire up the handlers that correspond to elements in
the 'new_stream_users' template when we render that template,
rather than at startup time.
We also delegate the events only up to #people_to_add, rather
than all the way up to body/document.
Added support for passing a filename without `.js` suffix.
This then fixed the issue of no complaints for invalid test
files. Now, throws an error for invalid test files.
Fixes#8579.
This cleans repeating code in error callback in settings.
We made a generic function in `ui_report.js` which require two
arguments `xhr` and `btn`; we preferred `btn` over `row` as argument
because a row may have more than one buttons.
Fixes: #8788.
This tests the initialize() function for now.
It goes deep on this:
* uses "mostly real" message lists
* asserts on fetch parameters
It stubs out many modules that aren't really central to
the logic of fetching. In particular, when messages are
processed, we notify things like the buddy list that messages
have been added.
An integration with RSS can be much easier to set up with Zapier.
Since the current RSS integration predates Zapier, we should at
least mention that there is an easier way to set it up via
Zapier!
This replaces the previous logic of triggering change() event.
(Also, when we trigger the change() event whole path for detecting
changes in a subsection are triggered which isn't good.)
This makes use of `settings_ui.disable_sub_setting_onchange` for
handling dependent `id_realm_disallow_disposable_email_addresses`
checkbox when `id_realm_restricted_to_domain` is changed.
On discarding changes made for `realm_create_stream_permission` always
"by_admin_user_with_custom_time" get selected because
`create_stream_by_admins_only` isn't a valid page_param.
This reverts success callback extension for `do_settings_change` function
because it seems it is better to make the request directly rather
than calling `do_settings_change`.
And hence `error` callback extension is also removed for the same
reason, but a error_continuation is added to do additional tasks when
errors happened.
For forms that are built early in setting up the settings panel,
we don't want to attach multiple submit handlers every time we
go into the gear menu, so we use "off" to clear any old handlers.
We also attach handlers directly to the form, instead of
using delegation up to the container div.
We only have one possible email hint, so there's no reason
to create one for each stream row, especially since we don't
clean them out when we close stream settings.
webhook-errors.log file is cluttered with Stream.DoesNotExist
errors, which hides the errors that we actually need to see. So,
since check_message already sends the bot_owner a PM if the webhook
bot tries to send a message to a non-existent stream, we can ignore
such exceptions.
We don't have any consumers for this event after removing
some obsolete code related to subscribe buttons.
Handling this event reliably consumed about 75% of the time
spent in _post_process_dom_messages, and maybe a percentage
point or two of overall rendering, so this will be a minor
speedup.
Shubham Dhama
Rohitt Vashishtha
Marco Burstein
sinwar
Tim Abbott
neiljp (Neil Pilgrim)
Puneeth Chaganti
Steve Howell
Joshua Pan
Umair Khan
Eeshan Garg
Ricky