This was supposed to be suppressed when a reload is in progress,
however, the logic was accidentally checking that
reload.is_in_progress was a defined function, not whether a reload was
actually in progress.
There was previously a race condition where reload.is_in_progress was
set after `activity.js` sent the presence request to the server, but
before we process the response; in that race condition, we still
shouldn't send blueslip errors to the server.
This renames Realm.restricted_to_domain field to
emails_restricted_to_domains, for greater clarity as to what it does
just from seeing the setting name, without having to look it up.
Fixes part of #10042.
Fixes part of #10026.
Typeaheads stopped propogation of keydown and keyup events for any
key except tab and enter. If stopAdvance was true even tab and enter
were not allowed.
advanceKeyCodes option was added to typeahead which allowed to specify
key codes for which propogation of keydown and keyup events should not
stop. advanceKeyCodes does not respect the stopAdvance option.
As the backspace key code is added to advanceKeyCodes in search.js,
the backspace key deletes pill on pressing backspace if input is empty
or only consists of spaces.
This optimize the case when the user-info-form modal is opened
in user-list by not rendering bot_owner_select handlebar.
This bug is before changing form to modal.
This is sort of a temporary fix to bring the state back to how it
was in commit: ef4337edcb. However,
long-term we will need to fix our local echo feature to do merging
of names just like we do on backend.
We don't need to get sorted streams in the "source"
function for typeahead, since we sort them later,
and we don't need to recalculate values.
This preserves the behavior that we include
unsubscribed streams in the typeahead, which is
probably intentional.
This pulls the essential bucketing/sorting logic out
of filter_table().
The diff isn't quite as clean as I'd like, but some
of the code that got added back to filter_table() can be
eliminated in the future. Basically, all the stuff
related to hidden ids can just be zapped if we go
to an approach of just re-building the DOM cleanly
whenever our filters change.
We replace two calls to stream_matches_query() with
a single call to triage_stream(), which prevents us
from doing the same is-subscribed checks twice.
We probably should have done this a while ago, even
though these functions are pretty tiny. The goal here
is to make it easier to have more consistent search
semantics.
Our first use case is subs.js. In this case we
are able to decouple a bit of generic string
matching from the subs-specific code.
We move some data code from subs.js to stream_data.js.
It's not clear we have been using the optimal sort for
dealing with locales, but this change preserves the
current behavior. The only subtle change here is that
we look up subs using a Dict now instead of a plain
JS object.
The values of this dictionary used to be raw DOM elements,
but get_row() wraps them again, so there's not a huge
reason to store them as raw DOM elements internally. It
is slightly easier to reason about the code if everything
stays at the jQuery level.
To preserve the old behavior here, we have to do something
that is kind of ugly, but at least it's explicit now. In
the old code, our cache was DOM elements, and if an id
wasn't in the cache, we would sneakily return $(undefined)
with this code in get_row():
return $(this._rows[id]);
And it turns out that $(undefined) is basically just a
zero-element jQuery object. A lot of our code depends
on this behavior and just works around the zero-element
objects as needed with checks like this:
if (this.selected_row()).length === 0) {
// don't try to get offset
}
For now we just preserve this behavior. We could eventually
be more strict here, or at least have aggressive warnings
on cache misses, but we'd need to retrofit code to be
able to call something like `has_rendered_selection()`
and/or deal with `undefined` as the return value for the case
where the selection hasn't been rendered.
Here is some example code that would cause tracebacks if
we just returned `undefined` for cache misses:
rerender_preserving_scrolltop: function () {
// old_offset is the number of pixels between the top of the
// viewable window and the selected message
var old_offset;
var selected_row = this.selected_row();
var selected_in_view = selected_row.length > 0;
if (selected_in_view) {
old_offset = selected_row.offset().top;
}
return this.rerender_with_target_scrolltop(selected_row,
old_offset);
},
This function is more cohesive and always takes in
a jQuery object containing exactly one DOM element,
and it does all stuff at the jQuery level of
abstraction (no raw DOM).
It's a pretty simple extraction--removing the level
of indentation makes the diff a bit noisy.
We shorten the name of the function and avoid having
all the callers call `.get()`. Now we mostly stay
in jQuery "space", which avoids some confusion about
when we're dealing with raw DOM elements and which
will facilitate unit testing.
Changed search pill padding, `.navbar-search` flex-wrap to match with
the CSS refactoring in 66df4e3e84.
The `height: 100%` changes to `.navbar-search` and `.input-append`
make up for the issue in which the pills overflowed in the mobile
view due to `.navbar-search` height being declared 40px explicitly
while the actual heiight in mobile view was shorter.
Currently on zoom out from stream topics, scrollbar didn't scroll back
to opened stream. Because call to scroll-to-stream func isn't called
after all streams view is displayed. So wrong stream element is
passed to func.
Fix this by calling scroll-to-stream func after all-stream-list view
is displayed.
We use these new functions in the message compose typeahead so that they
can also be used in a PM recipients typeahead with both people and user
groups.
We now render the "skin" part of "Stream Settings" before
adding in the actual streams. The new function
populate_stream_settings_left_panel() takes care of adding
the streams. It uses a new template called
`subscriptions.handlebars`.
Splitting out this function will give us more flexibility
for various improvements.
First, we can decide to render the list after we open the
overlay, just to avoid the problem that users don't know why
the modal's opening. (And we could add a loader spinner as
needed.)
Second, we can improve our filter features so that we do
filtering in the data instead of moving DOM rows around,
which is expensive.
Third, we can eventually introduce progressive rendering.
Finally, having the function broken out will make profiling
more precise about where bottlenecks exist.
Fixes#10059.
In 66df4e3e84,
`display: inline-flex` was added to `.pill-container` but
`flex-wrap: wrap` was missing which forced overflow pills to be on
one line and made the pill text overflow vertically. This was not
observed in composebox pills as `.pm_recipient .pill-container`
already had a `flex-wrap: wrap` rule which has been removed in this
commit to avoid duplication.
We were passing this in before, but having it as
a data member reinforces the idea that we'll want
this to be a first-class concept in the list, since
we depend on ordering for various things.
We now keep track of keys in buddy_list.js, so that
when we insert/remove items, we no longer need to
traverse all the DOM. Instead, we just find out
which position in the list we need to insert the
key in (where "key" is "user_id") and then find
the relevant DOM node directly and insert the new
HTML before that node. (And of course we still
account for the "append" case.)
There's a little more bookkeeping to make this
happen, but it should help reduce some code in
upcoming commits and pave the way toward
progressive rendering optimizations.
This commit should produce a minor speedup
for activity-related events that go through
buddy_list.insert_or_move(), since we are
not traversing the DOM to find insertion points
any more.
This will be useful for lazy rendering, where our
buddy_list widget already knows the keys (aka "userids")
it wants to render as you start scrolling them into
view.
