This helps the edit form in particular, when you change a
topic and need to select the propagation option.
(imported from commit c9dd1e62cd9e0b2142855685f04baa06eecf7226)
If we get a topic change, we can change the subject outside the
loop, since we are passed in event.orig_subject. Doing it inside
the loop was mostly harmless, since after you encountered the first
message with the old topic, the condition to change the subject
evaluated to false, but it was still technically O(N), and it was
kind of confusing.
This commit changes behavior in the edge case that you have the
compose box open for a changing subject, but you are in a narrow
that does not have any of the affected messages. After this commit,
the topic in the compose box will still change, which I believe
is the correct behavior.
(imported from commit 2363e432ebe7ae8e07379324ee0bfb52051428e6)
Before this change, we were incorrectly trying to do local
filtering on negated has searches.
(imported from commit d1a6f1feef6b3cc1c984eb91a73cd16c4e66874e)
We show a user as "on mobile" if:
* They are only active on mobile
* They are inactive on all devices and can receive push notifications
(imported from commit 0510b9371727cd19c72f6990df7112921c36ad48)
This doesn't affect code when not in testing. It shaves 7 seconds off of casper
test time on my machine.
(imported from commit 7e27fa781bcf16f36d9c8f058427ba57c41068bd)
This speeds up CasperJS tests by 25 seconds per main app page load.
When we switched the SockJS, the casper tests got inexplicably slower. I
finially figured out what's going on. The first SockJS XHR request (remember
that we don't get websockets in the test suite) gets considered part of the page
load and therefore the PhantomJS onLoadFinished handler doesn't get called until
the SockJS XHR finishes, which happens at the heartbeat, 25 seconds later. To
fix this, we simply don't create the SockJS object on page load since it will be
created on demand, anyway.
(imported from commit 845a97526c5102df426cd6fc26182a734e7fcab6)
Catch any exceptions that happen in the process of triggering
the message_rendered.zulip event. This addresses #2356.
(imported from commit ce771483cd2533d312fbd68e9c2753c80b3c8d49)
Our restructuring of the messages (especially grouping) seems to be the culprit for message copy and paste
(imported from commit 14632a67f55efea4f1b53cc718a4f655ac83b387)
This addresses #2351. While I could see the argument for
wanting to edit a message without changing your selection,
I think it's just very surprising behavior and inconsistent
with the rest of the UI.
(imported from commit 3bb4faca0656258b76bfaafbd7f4a645810578f6)
See #2357. We now support `~~~ .py ` with that trailing space.
Note that the test coverage is Python-side only due to
bugdown_matches_marked being set to false, since we don't yet
support language syntax on the client side.
(imported from commit ccd5fcb0eee01478d349161400103480678d7486)
Previously, if you searched for "in:home search:foo", we
weren't making "in:home" a public operator, so the back end
wouldn't know to exclude muted messages, but the front end
also wouldn't exclude muted messages, because it assumed
that queries with "search:" in them were fully narrowed by
the back end.
Prior commits made it so that the back end is now capable
of doing "in:home" narrowing, so to get the properly narrowed
results, we simply needed to make in:home be a public operator
in this commit. We also made in:all be public for convenience,
although it's essentially a no-op.
(imported from commit e4a8b10813b50163c431b1721bd316b676be1b83)
This commit finishes up support for has:* searches by adding
the front-end pieces, specifically the part that "has" operators
will not be applied locally. It also implements basic
descriptions for search suggestions and canonicalization
of operands from plural to singular.
(imported from commit a3285bc33d06d76b5a2b403ebcdd911b4cc03980)
This fixes#730, which includes any customers we want to notify
about the feature being pushed.
(imported from commit c60959ddd7c61ea8e014e984047e9f7bc0d59296)
Typing "stream:foo -topic:b" leads to "stream:foo -topic:bar" properly
as a suggestion now.
(imported from commit bb0acf52744f7b13977a3db5d3c130d1402b09b7)
This doesn't change the alerting UI logic, it just turns
alert_words_ui into a module and calls the setup code from settings.js
when the settings page is rendered.
(imported from commit 05f95383b046086641280f82f648be58688efe61)
We should hide the empty narrow message message whenever the narrow is
not empty, but we should only select a message if non are currently
selected.
(imported from commit 22f6b0827dc84ed587a83b5d713b12c1d5d4c0a0)
When reloading the page we want to narrow to the location that is
restored from the query parameters. This is only done if we ask narrow
to use the first unread message from the server.
(imported from commit b585ef51cbb85788b24d90d831b42c45fd188569)
The reload initiation is required to run before other parts of the site
are started so that page_params will be setup correctly. This moves that
initiation out of an on ready handler to an explicit initialize call
near where the rest of the app is started.
(imported from commit b8994311299327aa3cfa57e3d9e92124a47123f4)
rerender_messages() does extra work such as making rerendering in narrows
safe, as well as updating recipient bars. That should be the only valid entry
point for rerendering individual messages
(imported from commit f91aeb2070b1056ab95e01d68a342558c2813ae8)
