We are seeing error on CUSTOMER4 when clearing the DOM on reload. So
now we will only clear the message list.
(imported from commit f5d8d7d36cd1018f7def73ff9eda414387fcec5c)
Previously, you'd have to be offline to recieve missedmessage
notifications, or maybe idle for an hour. However, I'm pretty sure the
latter code didn't actually work, so we scrap that and just nofity you
via email or push as soon as you're idle.
Closes trac #2350
(imported from commit 899966e0514db575b9640a96865639201824b579)
Since it's basically impossible to add a person with an
undefined full_name--even "skeleton" people--there is no
need to check the full_name field to short circuit reify(),
because it will always be defined.
(imported from commit 3a30cfd583a040f7460739abea1604594c450ffe)
Closing the edit box earlier will make future changes less brittle,
when we, for example, re-narrow based on topic edits.
(imported from commit 36219c5129153beebfefe443932825fdf74abc43)
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)
This includes removing GET support for the endpoint, which is unused
and doesn't map well to this being a bulk endpoint.
(imported from commit 348ff9dfa84be1661368c6d7d35aebf2ae2a9ae0)
This helps the common case of not liking our default of having audible
and desktop notifications enabled, and not making users adjust the
settings on every existing stream to fix it.
(imported from commit be75edb2c1385d1bd9a289416e2dffd8007f5e0a)
They have weird properties like not sending anything for unchecked
boxes, which makes it hard to wrap a client-agnostic API around.
(imported from commit fef73a57a55b218b55dab6be3453dd6eac73c789)
`#tab_bar_underpadding` overlaps some with `.message_header`,
so adding `#tab_bar_underpadding.bottom + .message_header.height`
gave us a nonsense message viewport top.
Doing the calculation this way is more robust, as long as:
1) `$(".floating_recipient").offset().top` continues to give us a sensical number
and is the last element just before the top of the viewport.
2) nothing appears between the composebox and viewport.
In this commit I also removed the other couple of places where the #tab_bar_underpadding
was being used as a viewport reference, that no longer makes sense.
(imported from commit c7f35e41309900c581d5e2329c1becf161d501d3)
Jason Michalski
Steve Howell
Leo Franchi
Luke Faraone
Zev Benjamin
acrefoot
Waseem Daher
Jessica McKellar
Allen Rabinovich