There seems to be some sort of bug involving PhantomJS and XHR
streaming messages. When successive pages are loaded that use XHR
streaming, PhantomJS seems to think the second one never finishes
loading and therefore hangs.
(imported from commit db93b4cab816f1fdc3f3f543c9394b1cba8abedb)
Because our authentication system reads cookies from the initial
connection attempt, several SockJS transports can't be used.
(imported from commit 34b9571225d39072985b8223fb12c43c7235841f)
We want to deprecate reload_subscriptions(), which was kind
of a big hammer to use when only a single stream is being
renamed. Now we call stream_list.rename_stream() to update
the sidebar.
(imported from commit a77d09c0433d9b605b7baa7d7c61183bc8c37ba9)
For a large domain like HS, we were pulling back about 100k of
text with subscriber emails when we opened the Streams page.
This was unnecessary, as the subscribers aren't shown until
you expand the stream, and there's already an AJAX call.
(imported from commit 69b83d769030d87318acefc364ac6ff3a2ec3605)
Use the new count_full_messages_between instead of subtraction in
message_list_view.append. By finding a count higher than it should be
when summarized messages are present, it didn't add new messages until
the pointer moved under certain conditions.
(imported from commit c10d9c1a0d23891acce88bf8d79866c08cb75681)
Currently, code blocks end up with scrollbars annoyingly frequently --
even with a maximum width window, you can't fit a standard 80
character terminal worth without needing a scrollbar. This change
causes our code block text to be the same size as normal text and
inline code blocks.
(imported from commit c2fc7e008cc514e90387f8f0db2b49e357cf4f62)
Summary blocks can contain hundreds of messages. When the rendering window
code didn't take this into account, it would lead to all kinds of
unpleasant behavior when you scroll.
Trac #1888
Unfortunately, this replaces a subtraction with a function that iterates
through all the messages.
(imported from commit 9259a246946cd968a8725c38ff5ef2d4b4793717)
* Disable for search-like narrows (whitelist stream and home instead of
blacklisting topics and PMs)
* Use home view summarization flag for All Messages
(imported from commit 48bd10ae5da7c7564c2efe86a40078f1a7e96e20)
Don't warn when @-mentioning a bot on a public stream that it does
not appear to be subscribed to. It may be receiving those messages
anyway.
(imported from commit 4a00694942a721897a01736f48033c71048e0b16)
This doesn't address the more complicated case of someone @-mentioning
you on a muted topic, which consensus is you do want to get
information for, but we need to develop some infrastructure to present
that case to users clearly.
(imported from commit a4bc1e89c108fa8ba6eccc0a198eabf2231326ab)
Add the option "Narrow to just this message" to the chevron
menu. This has two use cases:
* It's an easy way to get a sharable URL for the message.
* It reduces distractions.
For now it is feature flagged to just customer12.invalid and staging.
See #1880.
(imported from commit 897d247176f9024ff825ccd3b338236569eed5ab)
Allow users to open Zulip windows in new tabs with command-click
from the left sidebar narrowing links and recipient bar
narrowing links.
(imported from commit d60c038c7bf1efccd461f5284d513b9cbfbdaebf)
If the user has text in the compose box, don't close or
change the compose box when they narrow.
(imported from commit f9b400f6bac37cb313f1fd87aadb3ba1d3a035ef)
For the two cases where narrowing should open the compose box,
we now put that logic inside of narrow.js.
(imported from commit 570e22e90c2f6d422ba71cce400c075f0b8adf51)
Handle closing the compose box inside of narrow.js, to
ensure consistent behavior for all the narrowing UI options.
(imported from commit f17a687491eb2361c73032cd974cedb2a0a2dd85)
The main user-facing feature here is that users can open narrows
in new tabs or windows. Internally, it makes the HTML more semantic.
One consequence of making these elements into actual anchor tags
is that clicking on them no longer triggers this logic to
close the compose box when you click outside of it:
// Unfocus our compose area if we click out of it. Don't let exits out
// of modals or selecting text (for copy+paste) trigger cancelling.
if (compose.composing() && !$(e.target).is("a") &&
($(e.target).closest(".modal").length === 0) &&
window.getSelection().toString() === "") {
compose.cancel();
}
Instead of patching the above code, I elected to just call
compose.cancel() explicitly in the click handlers for the links
themselves.
We are gonna try to clean up the compose-box behavior globally soon.
(imported from commit c9a01916f1714fe3dd495d25c78cd5e5532105ef)
I added comments to the section of the template that generates
recipient bars for stream/topic messages.
(imported from commit a7ea9353dc5db20db3410b9566f5e0d670eff31f)
Trac #1737
Firefox has the slightly broken behavior that it emits a click event on
the document when you right click, but not on any of the child nodes, so
our #compose stopPropagation doesn't stop right-click events from closing
compose. Chrome never emits click events on right click.
(imported from commit 2519c542715c93877b6d38e5dcff1f3e011688e4)
I'm not saying it's beautiful, but prior to this we bolded
the topic name, but we didn't bold the stream name or user name.
Now we uniformly bold the name of the thing you're taking
action on.
(imported from commit f48b9d267b73858263541a905f6fd7fd626068ba)
There's one place where we don't really get this right, though,
which is the Streams page -- there's still a checkbox labeled
"include in home view".
I'm basically OK with that.
(imported from commit 55319b57f0c3d005a9937258a55254b9a91ce6ae)
When decoding an operand, a + can be converted to a space
only if the operand is not an email address.
(imported from commit 08fc36a579bbe6409137c60c0fa9579fe3ab2c43)
It's a bit of a contrived use case, but you could make a topic
called "12345" and then mute it from the sidebar, and it would
crash inside Dict. We now call attr(), not data(), to avoid
string-to-integer conversions.
(imported from commit 89666f40d624df154d41077546e1c13a23ee7e67)
Before this change, you could narrow to an old topic, and it would
not show up in the sidebar unless it had unread messages.
(imported from commit f177a7378dac064e46a6417357cc86ada4475936)
The old code was looping through recent_subjects to find the
original subject name, but we already have logic in get_subject_filter_li()
to be case-insensitive. I tried this with various casings of topics,
narrowing to topics, as well as narrowing to a stream (so no active topic)
and narrowing to an old topic.
(imported from commit 1decde13477cb742fd4bc82798f1afb282182bdf)
Create our own objects for handlebars, so that we can add transient
flags like is_zero without worrying about side effects to other
code.
(imported from commit b351a369cb3f36233e108e270c7abdd4ab8c5860)
When we call rerender() on MessageList, it is usually because
something big has happened, so it's reasonable that the pointer
may now be invalid. As an example, the old pointed-to message
may been removed from the home view. We have always just
moved the pointer under the hood, but now we do it in a way
that doesn't generate spurious blueslip errors.
(imported from commit d399a101f36b744a423ea7da80dda8352440c6c9)
There is a scenario where we call process_read_message()
for a message that we haven't recorded as unread before.
I'm not sure how it happens, but I put back code to
guard against crashing. The regression happened in
5752458c821.
(imported from commit 5ce15d2e236b738b445ed88f1733aa0612be0ff3)
This fixes a blueslip error where we were trying to add the same
message into a MessageList twice. Muting complicates our duplicate
detection, because empty() can return true even when we already
are storing messages that just aren't shown (because of muting).
The name empty() should probably be fixed in light of muting,
but filtering with self.get() is not really a problem here.
(imported from commit 83b0890471c9a0aa21996f3d0d3be4a238f23e65)
We have been persisting muting preferences on the back end for
a while, but we haven't been adding them to page_params for the
client to have at reload/startup time.
(imported from commit d9ca68aa0e4d22bfb0e6ce67fc0bc63981175c8b)
With the muting/hiding features, it has become the case that
this._hash can have entries that don't map to actually visible
rows, so this.get() can return true on an id that shouldn't
actually be selected, causing downstream code to explode. Now
we call this.closest_id() regardless of whether the hash is
populated, to be safe, but then we still call blueslip.error
if the pointer moved.
(imported from commit 348e8ff67ce3a6d61aaeb31f80549386518af2d0)
If you have two browsers open for the same account, muting in one
browser will now be reflected in the other browser. This got
regressed when changing the approach from collapsing to hiding.
The new code should be less brittle, as we encapsulate re-rendering
in muting.rerender().
(imported from commit 4e65e265b64513d38f518770453b7436cb92b4ca)
Update get_counts() so that it ignores counts for muted topics
when calculating stream/home unread counts.
(imported from commit 9b4e4da4346c225c535e97d709d3dee032603cc5)
The indirection was more confusing than helpful, especially
since the function had side effects, despite its getter-like
name.
(imported from commit 85d9cf642b4177f62488136f0e0f7f6c9304942e)
After killing off unread_counts.stream, the only field of
unread_counts was "private", so I just made unread_privates.
(imported from commit 9678f5b03524afb883ec4fa638b059e698888e78)
The prior commit makes it so that we no longer use unread_counts.stream
in get_counts(). This commit removes the code that updates the
data structure.
(imported from commit 5752458c8212bf02cf9c8733ce349fc35b204a9b)
These two data structures are kind of redundant:
unread_counts['stream']
unread_subjects
We are deprecating the former. The latter is more flexible for
features like muting.
Now, in get_counts(), we compute home counts and stream counts
in the same loop that computes subject counts.
(imported from commit c8d0ea12a56d0128811e0aa165de9882546906a5)
For whatever reason, it makes it easier to compare the detail pages
when they are full width, since each column is in a more or less
consistent place every time.
(imported from commit cba47ac1a370884c0397d26d6028248f0b9cc9d7)
We are still showing the same data points, but the logic to drill
down on details for a particular realm is now all server side,
not client side, and we are smarter about omitting fields. In
summary mode, we don't show empty Name or Email columns. In
detailed mode, we show the realm as a headline instead of a column.
In this version you do lose the ability to see all system users in
the same view, but Waseem is ok with this.
(imported from commit edd2e646ab4cf5783ea64232d0cd621debece8d4)
When you load the activity report, it will just show summary
counts for realms, but if you click on a realm, you will see
details about users in the realms. You can also click "Show all"
to see an interleaved view of realms and users.
(imported from commit b106557b1fae64d525071afc124b5a8aed319086)
`Cannot read property 'flags' of undefined` in the
_.each callback in expand_summary_row.
Messages loaded when you scroll up in a narrow are not added to
all_msg_list. Because the user just clicked the message, we know
the message is in current_msg_list, so use that instead.
(imported from commit e76449a2a2748b96f69a2ab05d288b708d9e3ac0)
Instead of collapsing muted messages, just hide them altogether
in view where it makes sense to hide them.
(imported from commit 1c2c987ff302ceb135a025753cf421b4de1aea71)
I moved code into MessageList to further encapsulate details
of filtering. The MessageList instances should be their own
gatekeepers for what messages they care about.
(imported from commit ee6cd7f6eabf97962d724a05d7d0b0a3e6ab19e5)
Warn inside these functions when you get data on streams that you
are not subscribed to:
add_subscriber
remove_subscriber
user_is_subscribed
The back end should be smart enough not to spam us with subscriber
info that we don't care about.
(imported from commit b27644be2abc37c11ddff884ef392ea208bd1bd3)
The first menu option supported is to narrow to the topic.
The chevron only shows up if you turn on feature_flags.muting.
(imported from commit 17482f538a6d3e4ff96a36c042bad972d34f4b11)
Use the stream_data API to set up subscribers, so we don't
leak the data structure details into subs.js
(imported from commit e95616f2eb535ecf0e1cef35a143a71ad88de5bc)
This was requested by CUSTOMER28 and would also bring symmetry with
the user sidebar, which already does this.
(imported from commit 4dca3c957d3a710f00bbb34a7cd7dfe6074da8f7)
Though this should not be common, getting a peer subscribed/
unsubscribed notification to a stream we don't yet know about should
not be fatal
(imported from commit ee28b163e0efc9adfad31e1b321e986dfe56271e)
We create a blueslip error for undefined keys in Dict. This led
to a straightforward change in the unit tests for Dict. For the
unread test, to avoid the blueslip error, we had to be more specific
in setting up a user in one place, but this reduced our coverage,
leading to another small test being added.
(imported from commit 33e14795500d9283de2a7c03c4c58aec11cea4b8)
The exceptions were cryptic before, and they were inconsistent with
the fold_case: false behavior.
(imported from commit a40704d1a22bcdc60d91be832ee3c81eb416c6dd)
These engagement data will be useful both for making pretty graphs of
how addicted our users are as well as for allowing us to check whether
a new deployment is actually using the product or not.
This measures "number of minutes during which each user had checked
the app within the previous 15 minutes". It should correctly not
count server-initiated reloads.
It's possible that we should use something less aggressive than
mousemove; I'm a little torn on that because you really can check the
app for new messages without doing anything active.
This is somewhat tested but there are a few outstanding issues:
* Mobile apps don't report these data. It should be as easy as having
them send in update_active_status queries with new_user_input=true.
* The semantics of this should be better documented (e.g. the
management script should print out the spec above)x.
(imported from commit ec8b2dc96b180e1951df00490707ae916887178e)
people_list and people_dict include the feedback bot and anyone you've
cross-realm PM'd with. Useful for autocomplete, but not for admin and
stream settings views.
Fixes the UI part of Trac #1772.
(imported from commit cdefd4e86980447aad5190e7fc8ae3666d66e3c3)
hashchange, which calls admin.setup_page, runs in another onready
event handler before zulip.js main().
(imported from commit 5d4e71f4666baf0a53e3fe9804561ce6cdc06261)
This is feature-flagged to staging only.
There are basically 3 parts to the implementation:
1. In response to typing, fade/unfade the user list.
2. When a compose is aborted, unfade all users.
3. When the presence list is redrawn, fade/unfade the user list again.
(imported from commit cd416de232849a9f69dcacdc8b0fcfc20e3848a2)
This is the last step in getting a consistent client-side picture of who
is on a stream (provided non-MIT realm, and provided the local user is
subscribed to that stream).
(imported from commit 8bca722f169860ad4c1c92fdcb70d62c60f70fed)
This fix required upgrading to 1.1.17, but it's not squashed
with the upgrade, because that would complicate keeping the
copyright-fixing commit separate from the upgrading commit.
The new version of the plugin makes it so we can trigger a
resize event, but it's backward incompatible with our old
compose box code.
A minor cleanup here is that we also don't trigger a resize
right before hiding the compose box.
(imported from commit 6b0cb9ccd2ddef919fd375a80cfca535b5b74c0f)
Tim Abbott
Zev Benjamin
Allen Rabinovich
Steve Howell
Kevin Mehall
Jessica McKellar
Leo Franchi
Luke Faraone
Waseem Daher
Jeff Arnold
Jeff Arnold
Scott Feeney