If you go into "more topics" for a stream with many topics,
and then scroll down, and then zoom out again with "All
streams", we make sure the active stream is still in view.
We have code that can automatically scroll an element into "view"
in its container. We use this for stream sidebar rows inside the
stream list.
Generally the stream sidebar rows are small enough to fit into
the container, and the prior algorithm worked correctly for that
scenario.
If you have lots of topics, however, and a short screen, the
algorithm was being too aggressive. For example, if the top
wasn't showing, it would scroll the top into view, but at the
cost of scrolling the bottom out of view.
This fix makes the general scrolling algorithm more tame.
Part of the user-facing problem is that the element we pass
into the scrolling code for the stream sidebar rows is bigger
than the part of the row that actually should be shown on
screen. Nevertheless, it makes sense here to make the general
algorithm more robust.
If you read a message, then got a topic edit for it, we were
adding the message to our data structure of unread stream/topic
messages.
Now we guard against this in unread.update_unread_topics. I
no longer expose an update() method in unread_topic_counter,
since we really want to do the unread check at a higher level
to keep other data structures consistent.
Category 'All' -> text 'Filter by category'; icon chevron right when
the dropdown is closed, icon chevron down when the dropdown is open
All other categories -> text CATEGORIES[state.category]; icon chevron down
A large portion of the diff for landing-page.js is due to refactoring the
contents of integrations_search into top level UI update functions.
State flows as follows: dispatch(action) -> render(state) -> update UI
Routes now use pushState instead of hashes.
On transition between categories scrolling position is fixed,
and on transition between catalog and integration sub-pages the page
scrolls to the top.
The lightbox "v" shortcut should not show a user's avatar,
so this limits the scope of images it can choose to ones inside
of the `.message_content` div.
On some monitors it appears as though there's a slight gap between
the bottom of the wave and the top of the section below. This moves
the wave down a pixel to ensure the gap disappears.
Fixes: #6064.
This fixes the registration padding to not be really large. It was an
issue of margin + padding instead of using margin for both where the
result would be max(margin1, margin2).
This replaces the `startsWith` string prototype method with `indexOf`
because no versions of Internet Explorer support this feature, and
it really is not difficult to just use `indexOf` instead and check
whether the starting index of the full string is 0.
This keeps hotspot icons positioned at the front of the message
viewport but behind sidebars (i.e. the left sidebar has a z-index
of 103). Hotspots associated with elements outside of the message
viewport should be individually adjusted at the bottom of hotspots.css.
compute_placement utilizes the dimensions of the viewport, viewport location of
an element, and dimensions of an element to determine if a popover will fit
horizontally and/or veritically given its orientation. The default placement
is now viewport_center, which displays the popover, without an arrow, in the
fixed center of the viewport.
This should be particularly useful for hotspots on mobile or large popovers
that contain a lot of content. The property hotspot.location.popover can be
optionally set to fix the orientation of a popover (most likely to
VIEWPORT_CENTER).
This fixes the lightbox zoom issues that occurred on some browsers
due to the units of `deltaY` being in lines rathern than pixels,
making it incredibly slow to zoom.
This change simplifies how we mark all messages as read. It also
speeds up the backend by taking advantage of our partial index
for unread messages. We also use a new statsd indicator.
By the time we render messages, we will have set message.unread,
so we don't need to calculate it from flags.
We add a line to the local-echo path to make this explicit
in that code.
When we learn about updated message, a bunch of flag/boolean
fields concern us:
starred
mentioned
alerted
is_me_message
We now set booleans consistently with how we set new incoming
messages.
This code adds 'read' to message.flags and sets message.unread
to false.
It's not clear that the boolean message.unread is used in any
meaningful way, but we set it to false to avoid confusion. The
bankruptcy code was not doing this before.
Another quirk that existed before was that you could get two
'read' flags in a message when you declared bankruptcy. It's
also plausible that this could happen if you marked a message
as read via two different ways. It probably did not cause
user-facing bugs, but it would be confusing for troubleshooting.
Fixes#5032.
The new method borrows some code from the event loop
and unread_ops.mark_messages_as_read, and it is now
flexible about message_ids being marked as unread
even when there is no corresponding message in the
message store. For that scenario we still want to
update our data structures, which wasn't happening
before this change. (Generally, this was a non-issue
up until now, but it will become a bigger issue when
we start loading unread message ids from the server.)
This function allows us to see whether unread.js thinks a message
id is unread (as opposed to looking at the message itself). This
method is useful when we get notifications from the server that a
message has been read. In the future, we may not actually have
a local copy of an unread message, but we'll still know that it is
unread based on page_params. We'll want to update the data in that
case.
Going forward, we'll want to deprecate message.flags for most use
cases and just use the unread.js data structures to track unread
messages.
The prior implementation was needlessly complex. Both del() and
add() are cheap and idempotent.
With this change we no longer bother to delete a topic from a
dictionary when its last message is mark as read, since it doesn't
really help performance. We add a line to the tests to maintain
100% line coverage.
In a subsequent commit, we may have unread counts for
deactivated users. There is no reason to fail hard on these
scenarios; if there is no list item for a user_ids_string,
updating the unread count should be a noop.
It's not always clear whether user_ids are strings or integers, so
we explicitly convert them to integers for sorting when creating
keys for PMs.
To keep the tests passing, this commit removes some unneeded
defensive code in message_store.js that only applies to contrived
test input.
This is a redesign of the features landing page from the current style
that includes the new sections in a grid format as well as some new
high-quality sections.
Main reasons:
* Shouldn't be hardcoding welcome bot
* compose_actions.cancel() was not closing the compose box, for some
reason. It was working fine before commit a few up from here ("tutorial:
Remove rest of tutorial."), but I think possibly due to the fact that one
had to click a button to exit the tutorial (that could be wrong, it was
hard to pinpoint why it was working before that commit and not after.)
This code should be going away anyway once #5816 is resolved.
* .screen is no longer being changed by other parts of the tutorial
* first_run_message we don't need, since we're guaranteed to have a message.
* Changing to #home and narrow.deactivate are not needed since we're
immediately narrowing to PM with welcome-bot.
These have been replaced by the initial stream messages and PMs.
The two pieces of information that exist here and not in the initial stream
messages are a link to /integrations, and a demonstration of image
uploading/pasting.
I think the current information presented is already a lot, though probably
it would be good to work in integrations somehow. Image pasting should just
be done in a separate Zulip that demonstrates the many different formatting
features.
The overflow was set to "hidden". I'm unsure of how this was even
working on desktop, but the #user-presences div certainly would
not scroll on mobile. This enables mobile scrolling.