We now have a callback for whenever the compose
box gets autosized by our old vendored version
of the autosize widget. It calls code to
scroll up the message feed if we are newly
covering it.
Apparently, `puppet-lint` on Ubuntu trusty throws warnings for certain
quoting patterns that are OK in modern `puppet-lint`. I believe the
old Zulip code was actually correct (i.e. the old `puppet-lint`
implementation was the problem), but it seems worth changing anyway to
suppress the warnings.
We also exclude more of puppet-apt from linting, since it's
third-party code.
Use the placeholder `[uploading file]()` when uploading before the
upload has completed. This behavior prevents an image from being
improperly placed when typing after starting an upload. This is based
on GitHub's handling of image uploading.
Also, add tests to the `upload` Node tests and update existing tests to
account for the new behavior.
Fix#10305.
Empty "person picker" fields appear with a much smaller width than all
other custom fields. Increase the `min-width` of the field that it
matches the widths of other text boxes.
Fix#10414.
Also use name for selecting form in casper tests
as form with action=new is present in both /new
and /accounts/new/send_confirm/ which breaks
test in CircleCI as
waitWhileVisible('form[action^="/new/"]) never stops
waiting.
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.
