Adding one row to the Navigation table made the
Keyboard shortcuts dialog look ridiculous, and it
was caused by a design based around float-left-ing
that broke down when the size of the "Navigation" box
was bigger than the "Composing messages" box.
Now we use a div to enclose the top two boxes in
the modal.
(imported from commit 90288ec288d4cf3d50ed7f5bcb48c8bb3d033f19)
All usages of json_to_dict were replaced with the check_dict
validator. The check_dict validations can eventually be
extended to validate the keys and values of incoming data,
but now we just use check_dict([]) in all the places where
we had json_to_dict, which means we aren't checking for any
specific keys; we are just making sure it's a dictionary.
(imported from commit fc5add9a7ef149dfac2a9a6d9a153799c4c0c24d)
We now will match an alert word even if it is used at the boundry of
bolding, backtick escaping, or caret quoting.
Closes trac #2186.
(imported from commit 984bc63eb621772c95a01ca5c5bfeb190767f71f)
This reverts commit 462a3eb5e6b83f9d8091b83e3f8dc458236938ed.
We're reverting this to see if it is the cause of our recent CSS
performance issues.
(imported from commit 6a0b041cfcb6770bbfda0d354444bad2d64459ab)
For the Filter helper functions above, we generally want to
ignore negated search terms, since their existence should
really only impact filter predicates and nothing else on the
JS side. The exception is search, where even the existence
of a negated search needs to be noted to know that we can't
apply a filter locally.
(imported from commit 8bbb410a85fefed549d359e4c779a134ad830c11)
For negated search terms, we weren't explicitly setting
"negated" to false when callers left it undefined, which was
mostly fine, since undefined is falsey, but it is better to
define it explicitly for debugging/testing purposes.
(imported from commit 68a2790b510d17caed8ca11c38188545d1dcc347)
Behind a feature flag you can now do searches like this:
-pm-with:othello@example.com is:private
The "-" in front of "pm-with" tells us to exclude messages
with Othello from our search. We support "-" in front of
all operators, although the behavior for "-search:" and
and "-near:" doesn't really change in this commit.
Note that the filtering out of "negated" predicates only
happens on the client side in this commit. On the server
side we ignore negated predicates and send back a superset
of the results.
(imported from commit 6cdeaf32f2d493fbbb838630f0da3da880b1ca18)
To deploy this, the zulip_internal::base and zulip_internal::munin classes must
be added to nagios.zulip.net.
(imported from commit 50d6a4ed19fcc9c62c7104977d69043bf5b9bbf9)
IE sometimes returns the pathname without a leading slash. Also
location.origin is not supported and must be build manually.
(imported from commit fb64478aeaac0f17d31021b7c370ff56781b48d1)
This commit doesn't change any functionality, and it is
designed to make diffs for upcoming changes related to
negated conditions a bit easier to read. This diff
looks a bit noiser than it really is due to some
reindentation of continuation lines.
(imported from commit 64c1cba98faa4bad4eaad122dd3de119caa880c0)
This this removed one forced relayout of the page on unnarrow. This
saves about 100ms for me.
(imported from commit 0755f425abbe3d99b8a99765549a5bbf3c620b9a)
Previously, we saved the current_msg_list selected id and then
restored it as the home_msg_list selected id, which could result in
the home view loading to the wrong place.
This takes some already bad code and makes it even more in need of
refactoring, but it does fix a pressing bug. We should definitely
refactor both:
* the top of narrow.js
* the save/restore code in reload.js
after this, though.
(imported from commit bb2040219e4f545ba90bb04a696996cec2831484)
This makes it simpler to test between two VMs by allowing you to bind to
non localhost interfaces.
(imported from commit f70755533b52ff8c49fd916941d2210fb8c33b47)
This reverts commit 64aced74012101f3bdbd3a4e6066b46ad8e1f4ea,
which was always intended as temporary code until we upgraded
the back end to support dictionary-style narrow operators.
(imported from commit b8d3a19f3aad3d9d6a26b9dcc07f502c55b18edd)
The filter_term() function was supporting the transition
from using tuples for search terms to using dictionaries,
but now all of the JS code should be dictionary-compatible.
(We had already abandoned the tuples safety net on staging,
and a couple days of use have given me confidence we can
pull the shim code.)
The one side effect this change has is that search terms will be
initialized to {} instead of []. This distinction matters
when it comes to calling JSON.stringify on the search terms.
(imported from commit 1fbe11011d8953dbea28c0657cbf88384d343e00)
Steve Howell
Jessica McKellar
Jason Michalski
Leo Franchi
Luke Faraone
Tim Abbott
Zev Benjamin
Waseem Daher
Allen Rabinovich