This is general fix that makes sure that we
apply all message-modifying events after we
apply the events for the initial incoming
messages.
The particular scenario that was reported here
was when you would have two tabs for Zulip,
with one of them open and in a PM view, and
with the open tab being at the bottom of the
feed, such that incoming messages would be
immediately visible.
Now suppose the other person in that PM
conversation sent you a message.
The open tab would properly immediately
mark the message as read, and notify
the server. The problem was that the closed
tab would not process the main message event
until it "woke up", by which time the flag-update
event was bundled into the same event batch
as the main message event. We'd then process
the flag-update first, which essentially was
a noop, since the actual message wasn't in
the message store yet. The user would then
see unread counts increment in the closed tab,
while the open tab didn't increment. This
was confusing.
Now `server_events.js` processes the actual
message first and does the flag-update as part of a
`post_message_events` loop.
We include events for updating message flags,
deleting messages, and attaching submessages
to messages in the `post_message_events` array.
This bug was a bit difficult to simulate in a dev
environment, since you needed your "open" tab
to be in focus to simulate the race, but as
soon as you tab to another place to deliver
a message (whether from the browser or otherwise),
the open tab is no longer in focus.
I did this in the console of my "open"
tab to work around it:
unread_ops.process_visible = unread_ops.mark_current_list_as_read;
This problem was easy to reproduce, but it wasn't
entirely consistent. I often needed to send
several messages in succession to trigger event
batching and force the race condition. (This wasn't
precisely a "race", as events actually arrive in the
correct order; it was having them arrive in the same
batch that triggered the bug.)
Instead of using a hardcoded value for spritesheet dimensions,
automatically calculate it using `emoji_data`. This will free
us from updating it only emoji datasource update as well as
allow us to add google blob emojiset.
This commit fixes multiple invite-user-email sent to user.
In invite-user-form, submit-form click handler is getting
called multiple times on submit-invite-user-form event, which
results in multiple invitation mail to user.
Because, we registered same submit click handler multiple times.
Submit form click handler is registered when user opens invite-user
modal. If user opens modal multiple times, click handler get
registered multiple times.
We should register this click handler on `exports.initialize`
function instead of `exports.launch` function. This modal is unlike
other modal, where we append html when user opens modal. In this
case, we append modal on initialization. We only show modal when
user opens. So on initialization, modal element already exists,
register click handler on submit-btn element, on intialization
not when user open modal.
Fixes#10354.
We also remove some unreachable code. Calling
split() always returns at least one token, even
if it's just the empty string. This is tested
directly on this commit, plus messages with
empty content get rejected pretty early in
the execution path.
If a caller passes undefined to go_to, it is
almost certainly a programming error, so we
shouldn't silently ignore it just because
the current key is undefined.
We also avoid setting curr_key until we
validate the incoming key.
When non-admin users visit the custom profile fields settings page,
the `Sortable` error
Uncaught Sortable: `el` must be HTMLElement, and not
[object Undefined]
is thrown, with `undefined: undefined | No stacktrace available` being
shown in the browser. Fix this by only using `Sortable` if the user is
an admin.
Fix#10403.
In commit c293bb82c4 we changed
id_realm_invite_by_admins_only and realm_invite_required checkboxes to a
single dropdown so these lines are redundant now.
In user type custom field, field value is list of user ids. We weren't
converting list to json object in update event payload. This throws
error in frontend, cause we store stringify representation of custom
field value. Therefore, after update event is recieved field-value-
type gets updated to array from string which throws json parsing error.
