This commit changes the invite API to accept invitation
expiration time in minutes since we are going to add a
custom option in further commits which would allow a user
to set expiration time in minutes, hours and weeks as well.
Added a setting to the bottom of Settings > Display settings > Theme section
to display the reacting users on a message when numnber of reactions are
small.
This is a preparatory commit for #20980.
Previously, the confirm button would be disabled when the user
attempted to change the capitalization of a topic, but still keep
it in the same stream. This commit fixes this discrepancy.
This commit changes the behavior of the move topic modal in
'stream_popover.js'. Instead of relying on an error banner, it
will now disable the submit button whenever an identically named
topic exists in the currently selected stream. To accomplish this,
it introduces a callback, update_submit_button_disabled_state(),
and calls it in three cases:
1. When the modal is initially loaded.
2. When the dropdown is changed.
3. When the topic name is changed.
The case insensitivity of topic comparison has been preserved.
Fixes#21711.
This commit solves the bug which keeps the announce stream checkbox checked
for non-admin users when users are only allowed to create private streams
and not public streams.
The desired behavior is to not allow users to announce private streams, so
we keep the checkbox unchecked and disabled.
This commit fixes the above mentioned bug by removing the if-else block which
was executed after update_announce_stream_state (the function which handles
updating the checkbox considering if the realm has notifications stream or
not and whether the stream being created is public or private) and only checks
whether the realm has notification stream or not to show or hide the announce
stream checkbox irrespective of privacy of the stream being created.
This commit also fixes the handler to update the checkbox state on changing
privacy to update the checkbox state only on changing privacy value and not
on toggling the checkbox itself or changing post policy.
Fixes#21705.
This reverts commit a8fd535955.
This reverts commit 944781e873.
In an attempt to introduce code from mobile into web to match literal
emojis, the author inadvertently introduced a buggy and smelly change.
Probably best to leave the implementation of this in mobile where there
is more context about the shape of the emoji object available. Web
doesn't actually benefit from the additional behavior anyway.
See https://github.com/zulip/zulip/pull/21723#pullrequestreview-937051603
This commits adds an wildcard_mention_array which would contain the
mention tokens according to the message type. In case of PMs, it uses
only "all" and "everyone" mentions.
Fixes part of #21643.
This commit attempts to fix the suggestions typeahead for wildcard
mentions in case of PMs by using a conditional which checks for the
current compose_state and changes the string in parentheses accordingly.
In case of PMs, it uses the "(Notify recipients)" string instead of
"(Notify stream)".
There is no guarantee that the code passed into parse_unicode_emoji_code
is valid unicode. In the case that it is not, it might be better to
return undefined instead of throwing an exception: to represent a
non-parseable code.
For context, mobile currently returns custom emojis as emojis with
string names in their code property, instead of actual unicode.
Previously, these buttons were centered via flex, which meant that in
the rare case that a long list of private message recipients caused
the recipient area to line-wrap, these icons would be incorrectly
placed at the vertical center of the now multi-line block.
Fix this by setting an auto bottom-marging.
Fixes#21693.
Change the logic for rendering PM threads in PM section to
be in the same as that of topics view --
In default view, only recent 5 PM threads would be shown
and append the active conversation as the 6th one at last
if not present in those 5.
In PM section with unreads, a maximum of 8 conversations
would be shown and rest of them would be hidden behind
the 'more conversations' li-item, clicking on which takes
to the zoomedIn view of PM section where all the present
PM threads would be visible.
Co-authored-by: Tim Abbott <tabbott@zulip.com>
This PR implements checking for a literal emoji match in emoji
typeaheads. In other words, if you paste or type panda face into an
emoji typeahead, panda face should be presented as an option to choose
from.
This behavior is currently present in the mobile app, adding it to
shared will enable both platforms to utilize this logic.
The old link here broke once we introduced separate APKs per ABI,
in zulip/zulip-mobile#5296.
We could make a direct link to app-armeabi-v7a-release.apk , the one
that's compatible with almost all devices. But perhaps better is to
just go back to linking to the release page, where the user can
choose the best APK for their device. (If they're in the habit of
downloading APKs manually to install on their device, then probably
that means they're going to be used to choosing the right one.)
User report and discussion:
https://chat.zulip.org/#narrow/stream/48-mobile/topic/Direct.20apk.20download.20link.20is.20404/near/1358758
marked.js provides a helpful error message asking for bugs to be
reported upstream, but since we're running a fork, we should redirect
such support requests to us.
We can triage as necessary.
This makes parse() more re-entrant.
This also drives out a change to the linkifiers
test, where I no longer couple the linkifiers
logic to markdown concerns. I probably should have
done this in an earlier commit, but better late
than never. I didn't bother to split out a commit
for the test stuff, since it's just tests and
the commit is still fairly atomic in nature.
It has always been pretty arbitrary what we did inside
of setup() vs. parse(), and we want to avoid unpredictable
results from other platforms neglecting to call setup().
On my machine you can parse a simple message in about
25 microseconds, based on a trial of a million messages
with the content of "**bold**". Whatever portion of
that time is related to setup-related things like
compiling regexes should be negligible from the user's
perspective, since we never run parse() in a loop.
We only need to loop through the preprocessors
once, and we should use the options passed
in to the parser, not the default options
from the original setOptions call.
The first loop here was doing nothing.
Our sub (i.e stream) and user_group objects have a bunch
of fields that aren't relevant to markdown parsing, so
we create narrow types that make it easier for us to
share code with mobile in the future.
I considered working purely in id space, but the problem
there is that user-entered stream names and user group
names need to be canonicalized.
The abstract_map() helper clarifies that our code
doesn't need a concrete Map object from JS. This
change is possibly premature until we get a little
bit closer on integrating with mobile, since it
solves kinda the same problem that we might handle
more elegantly with TypeScript or Flow.
OTOH I find it to be pretty non-intrusive for the
webapp.
These are the low-hanging-fruit places where we
can avoid using the helpers global.
The long term goal here is to make the markdown
code truly re-entrant, but some challenges still
remain.
Before this change, we would use **some** options relating
to parsing messages, but not all of them. The reason for
this was completely unintentional.
It's mostly a moot point, since the server sends back pretty
generic messages when you do something like invoke the
"/dark" command, and the message would parse the same way
whether or not the parser was looking for things like user
mentions or stream links.
In order to make this code predictable, I had to decide
whether we do a completely vanilla parse or a full message
parse. My decision now is mostly tactical. It's a trivial
one-line change to just use all the options for message
parsing, whereas it requires a major overhaul to allow a
vanilla parse.
I also predict that we will eventually want to parse these
server responses as if they were messages. I doubt the
zcommand responses would ever take advantage of it, but I
could imagine things like nag messages wanting to use user
mentions.
Even if my predictions are wrong, my decisions here are
pretty easy to reverse once we learn more.
For the particular case of zcommands, it is puzzling to me
why the server doesn't just send back HTML, but I don't want
to open that can of worms yet, as that would technically be
an API change.
For now I am happy with the one-line fix.
The zcommand code was calling directly into the "marked"
library, which was extremely misleading, since you don't
get a vanilla parse of the markdown due to the fact
that markdown.js calls setOptions at initialize time.
This commit shifts the responsibility to markdown.js
as well as adding a bit of test coverage, but it is
otherwise just a pure code-move refactoring.
The next commit will tweak things further.
This is mostly done for correctness reasons--it is
easiest from a logical standpoint to set the realm
emojis at the end of the function, since we do not want
them to be overwritten by normal emojis. The code
worked before this change, but it involved a clunky
check to map.has().
There is also probably a very minor performance
improvement insofar as N (the number of normal
emojis) is typically greater than R (the number
of realm emojis), and we eliminate N calls to
map.has in return for R calls to map.set. Even
if R is quite large, the readability advantages
probably far outweigh any performance considerations,
since we are using native map calls.
Thanks to Austin Riba for this suggestion.
The mobile app was never able to use the shared
version of emoji.js, because, among other problems
with our code organization, the emoji.js module
is strongly based on a mutate-the-data paradigm
that doesn't play nice with React. The way
that we mutate data and violate encapsuation
here is something that we would mostly want to fix
without even trying to shared code with mobile, so
subsequent commits will try to extract some pure
functions into a shared module.
The backend validates that URL inputs are RFC valid URLs (with no
specific length limit), but the frontend appears to have a maximum
length of 50 specified, likely because of a copy-paste error.
Increase the HTML maxlength for this input to 2048, which is a length
supported for URLs by all major browsers.
Fixes#21633
This commit fixes the template of stream deactivation modal
to tag all the text for translation. This commit also removes
the unnecessary span element.
The feature deactivates the bot user; Zulip has no "delete bot"
feature. So fix the label to match what it does.
We also change the icon to match the one we use for deactivating users
in the "Manage users" UI.
For user who is not an administrator.
Also implemented a banner that notifies the user if they can edit
the following settings (name/description and stream permission).
Also increased padding-top of stream header by 10px. This change is done
to increase vertical spacing between the banner
and the stream header.
Fixes#20001.
Fixes#21619
We need to adjust height of recent topics along with the app
otherwise the container becomes separately scrollable due to
it overflowing the app height.
This is definitely better than having linkifiers
reach directly into marked.js, but there is
probably further improvement we can do here
to clean up how these regexes get set.
This introduces a circular dependency between
markdown.js and linkifiers.js, but we will
soon break it in the other direction.
Note we now avoid linkifier checks for the case that a message
contains more obvious backend-only syntax such as attachments.
The next commit will eliminate the ugly early-return.
This gets us closer to having an API that can
be used my mobile.
The parse() function becomes a subset of
apply_markdown() that is no longer coupled
to the shape of a webapp object, and it can
be supplied with a new helper_config for each
invocation. Mobile will likely call this directly.
The setup() function becomes a subset of
initialize() that allows you to set up the
parser **before** having to build any kind of
message-specific helpers. Mobile will likely
call this directly.
The webapp continues to call these functions,
which are now thin wrappers:
* apply_markdown (wrapping parse)
* initialize (wrapping setup)
Note we still have several other problems to
solve before mobile can use this code, but we
introduce this now so that we can get a head
start on prototyping and unit testing.
Also, this commit does not address the fact
that contains_backend_only_syntax() is still
bound to the webapp config.
We were showing the push notifications tooltip in user default
settings section even if the push notifications were configured
on the server.
The bug was because the setting value was undefined in the template
used for user default settings section, so this commit fixes the bug
by correctly passing the setting value to relevant template file.
Fixes#21602.
This is the same sound that since zulip/zulip-mobile#5221 has been
the default notification sound for Zulip on Android.
The actual sound was created by Anders.
Co-authored-by: Anders Kaseorg <anders@zulip.com>
This is especially to add more space around the globe icon since
it wider than lock icon, so the previously set padding for the
stream icon has to be increased.
We use `fadeOut` effect to hide the scroll to bottom button more
widely. We already use `fadeIn` effect to display the button
every time.
We deliberately don't use the `fadeOut` effect when doing
`make_compose_box_full_size` to avoid any button overlap with
compose for a short time.
The implementation closely follows `handle_deactivation()`.
Using the same existing reactivate confirmation modal.
Also, this commit will also lead to open confirmation modal
to reactivate bots in settings > bots, and currently there is no
existing confirmation modal for deactivating bots.
This commit is a follow-up of #21436.
We previously added support for showing the status_emoji to the PM
list, but we only supported individual PMs and not group PMs, this is
prep commit towards supporting group PMs.
We previously added support for showing the status_emoji to the PM
list, but we only supported individual PMs and not group PMs, this is
prep commit towards supporting group PMs.
This change was motivated by the addition of status emoji to the buddy
list. Previously there was no spacing between the status emoji and the
unread count, and as such, this commit adds a left margin to the
unread count.
The above change has an additional consequence, long user names such
as "Othello, the Moor of Venice" get truncated with ellipses, instead
of reaching to the edge of the unread counts (as they previously
would).
While the 2px value that we had previously chosen looked alright for
most emoji (😀, 😃, etc) some emoji such as 🐙
used more of the width available to them and as such still looked too
close to the user name. As such this commit bumps the value to 3px
(4px was a bit too much space).
Previously, we were experiencing a regression in the positioning of
the play icon for youtube previews, as such, this commit uses a
previously created `handle_video_preview_mouseenter` to ensure the
positioning is always correct.
This is an ugly way of doing things, because this could be handled
directly through CSS flexbox, however, it is an acceptable temporary
fix.
This commit extracts the logic used to ensure that the play icon is
correctly positioned over the video preview for embedded videos, with
the intention that we can use this to fix a regression in the play
icon positioning for youtube video previews.
We render a login button for images that failed to load for
spectators. The image failed to load most likely due to being
rate limited by the server.
Fixes#19840
f0c680e9c0 introduced a call to
message_helper.process_new_message without first calling
message_store.set_message_flags on the message.
This resulted in it being possible as a race, when loading the Zulip
app to a stream/topic/near narrow, for a message to have the
`historical` flag be undefined due to not being initialized.
That invalid state, in turn, resulted in the message_list_view code
path for rendering the message feed incorrectly displaying additional
recipient bars around the message.
We could fix this by just calling message_store.set_message_booleans
in this code path. However, this bug exposes the fact that it's very
fragile to expect every code path to call that function before
message_helper.process_new_message.
So we instead fix this by moving message_store.set_message_booleans
inside message_helper.process_new_message.
One call point of concern in this change is maybe_add_narrow_messages,
which could theoretically reintroduce the double set_message_flags
bugs detailed in 9729b1a4ad. However, I
believe that to not be possible, because that call should never
experience a cache miss.
The other existing code paths were already calling
set_message_booleans immediately before
message_helper.process_new_message. They are still changing here, in
that we now do a cache lookup before attempting to call
set_message_booleans. Because the message booleans do not affect the
cache lookup and the local message object is discarded in case of a
cache hit, this should have no functional impact.
Because I found the existing comment at that call site confusing and
almost proposed removing it as pointless, extend the block comment to
explicitly mention that the purpose is refreshing our object.
Fixes#21503.
This eliminates an annoying bundle of complexity that caused the
frontend markdown processor's interface with the rest of Zulip's new
message processing code paths being more similar to that of a new
message from the server.
It also cuts down on code duplication.
The previous message.unread block in insert_local_message was
non-functional. markdown.apply_markdown is overriding what that set by
calling message_store.init_booleans, which happens to set the same
value for the `unread` flag, and then setting individual message
booleans as it finds elements like mentions during rendering.
Improve this situation partially by deleting the message_unread block,
and adding conversion logic to translate what the markdown processor
is doing into message flags.
Then, we can call message_store.set_message_flags just like we do when
processing new messages arriving via the API. This will be helpful
shortly, when we deduplicate the calls to
message_store.set_message_flags.
As noted in the lengthy TODO, this exposes the fact that we should
really rework how the frontend markdown processor returns the
mentioned state to its caller.
At the moment we fit only a single image per message per line. This is
wasteful of space as multiple images can be accomodated per line on
widescreen displays. This commit modifies the rendered_markdown
stylesheet to make this possible.
The comments detail various technical considerations.
Fixes#20975.
This revised globe icon avoids looking like a "language choice" icon
(as the previous one did), while still being recognizably Earth (and
not a disk with some things drawn on it) and not showing only North
America (a flaw with the Font Awesome 4.7 icon).
Used a derivative of icon from
https://unpkg.com/ionicons@5.5.2/dist/svg/earth.svg
with modified outline by Vlad Korobov.
There is config_data for the embedded bots only for giphy and
followup bots, so we send "config_data" field to API only for
those bots and not others. Send config_data field as {} to
the API for other bots raised InternalError earlier.
On changing bot owner, "delete" event is sent to the previous
owner if previous owner is not an admin. We were ignoring the
"delete" event in webapp previously, but now we update the
bots page in personal settings to delete the bot. Note that
we do not remove the bot from the organization list of bots
currently, since list_widget does not support removing a
row as of now.
In case of previous owner being an admin, the previous owner
receives "update" event and thus the bots list is updated
from that event.
The code for ignoring "delete" event was added in fba2708bbc,
to basically avoid failed lookup for id in the organization
list of bots. I have tested and there cannot be a case of
a failed lookup in the list as per current code for list_widget
module and we are anyways safe after a reload or after closing the
overlay as the list will be updated correctly.
Discussion thread -
https://chat.zulip.org/#narrow/stream/321-settings-system/topic/List.20render.20.2315033Fixes#20856.
The "download" attribute on the button only functions for same-origin
requests; thus, the download endpoint must be used in order for the
"Download" button to function for uploaded images which are stored in
S3, and thus served from a different origin.
This is only done for uploaded images; it does not address a similar
problem with Camo, when Camo is hosted on a different hostname.
Fixes: #19238.
Previously, the maximum width for the topic input in the compose box
was artificially limited to 20% of the width of the compose box.
While this may have had some useful role in encouraging short topics,
we can teach that idea in other ways, and it seems more helpful to
have the input length match what works well for viewing topics in the
left sidebar without being cut off.
Currently, when deactivating a user, we have a "Saving..." loading
indicator and any error message displayed in the heading area of the
users table.
Migrate this to instead do the loading indicator and error message
inside the modal, where it's more in context.
Improved the contrast of ? and i icons by changing their opacity to a
consistent 0.6, going to 1 on hover.
Changed the colour of playground icon by testing and added spacing
between title and the playground icon by changing the icon margin.
With some TODO comments added by tabbott for readability.
Fixes part of #20484.
Close buttons are misaligned if the warning banner text takes up two lines.
We increase the specificity of the selectors to ensure that this CSS
overrides Bootstrap.
Fixes#20839.
As detailed in this conversation:
https://chat.zulip.org/#narrow/stream/137-feedback/topic/recent.20topics.20timestamps/near/1337670
This time format change is not working out as an improvement for at
least some users, myself included.
I think we do want to use some of the refinements attempted here (and
in particular, I'm keeping the new function with its nice test suite),
but I think it's better to revert now and fix forward in a future
release.
See #19775 for added background.
Render tooltip to stream_sorter_toggle buttons using
appendTo method of tippy.js to ensure that tooltip doesn't
get hidden behind the parent container and is visible
completely.
Fixes#21329.
Previously, hovering over the table headers in the code playground
table in the dark theme looked wrong. We were able to trace this issue
to the table-sticky-headers class not having been applied to this
table. The `alert-words` table was also affected and is fixed as well.
This also adds the `actions` class in alert-words table to fix the
inconsistency of the actions column in that table.
We've done an audit and these are the only two instances of either
bug in the HTML templates for a settings table.
This commit adds a tippy tooltip to the lightbox title which enables the
user to view the filename of an image if the filename is different than
the image title.
Fixes: #21333
This commit adds a tippy tooltip for inline image previews in messages.
There exists some (reasonable) logic in `static/js/util.js` which
overrides all title attributes for links to user-uploaded content to
ensure they always display "Download <filename>". This doesn't make
sense for inline images specifically because they will be opened in a
ligthbox, so we prevent that.
There is an additional tippy instance created in `static/js/tippyjs.js`
to add tippy tooltips to inline images, which takes advantage of the now
preserved title attribute of the parent link.
Creates a helper function in `message_edit.js` that loops over
a message's edit history to see if a stream and topic pair
existed at some point in the message history.
Exports `util.lower_same` function to use for comparing
edit history topics as lowercase.
Also adds test for new function in `mesage_edit` node tests.
We check if stream and topic present in the URL match that of
the message in its current state. If message is not available locally,
we fetch it before rendering the narrow.
Fixes#15290.
It turns out that the bug this call hopes to fix only happens when the
user first loads the page to recent_topics and then navigates to a
view with a message list (any other view), but we'd make this call
every time the recent topics table was hidden.
Hence, this commit makes it such that we only make that call if (1)
the page is loaded to recent_topics and (2) we're switching from
recent_topics to a message list view for the first time. We achieve
(1) via binding a handler via ui_init.initialize_everything and (2) by
binding the handler as `.one`, so that it's unbound after its first
invocation.
Additionally, we use window.requestAnimationFrame to prevent this
forcing the browser to do a reflow unnecessarily.
Combined with other commits in this series, this fixes a major
performance problem when leaving recent topics for another view.
See #20255 for details.
The name for a BigBlueButton meeting is now generated from the stream
name and topic name.
The createTime option is used to have the user redirected to a link
that is only valid for this meeting.
Even if the same link in Zulip is used again, a new createTime
parameter will be created, as the Meeting on the BigBlueButton server
has to be recreated.
Fixes#16498.
Fixes#20509.
Fixes#20804.
The previous logic didn't make sense -- the scroll offset in recent
topics is not a scroll offset within a message list, so saving it was
useless at best.
However, it was actually much worse than that, because trying to save
the pre-narrow offset while in the process of navigating away from
recent topics had the side effect of forcing a reflow, which resulted
in very expensive browser rendering to no purpose.
Adding this commit to the rest of the series of commits fixing
rendering issues when leaving recent topics, this commit results in an
impressive 3.05 s decrease in the first renarrow, an ~ 300 ms decrease
in the second renarrow and an ~ 500 ms decrease in the third renarrow.
There are still further forced reflows which could be reduced in this
render path, but they seem to not be as severe.
This is partially a prep commit to correctly saving/restoring the
position of the blue message select box when using browser
back/forward navigation, and partially a bug fix that ensures that
switching from "all_messages" to "recent_topics" preserves one's
position in "all_messages".
Note that this is with regards to saving the visual position of the
selected message, not about saving "which message was selected".
If the target user is deactivated, `Reactivate this user` will be
shown as one of the options in the small user profile popover, where
`Manage this user` would usually be.
We rename `show_manage_user_option` to `can_manage_user` because now
it will also be used as the common condition for whether the current
user has administrative permission to active or deactivate the target
user.
The implementation closely follows the existing deactivation modal.
Fixes#21428.
chat.zulip.org discussion:
design > reactivate user from user popover
When a user clicks outside the typeahead menu, inside the typing area,
the cursor position potentially changes, so `lookup` is called, which
considers the new cursor position and accordingly hides, continues
showing, or updates the typeahead menu.
This fixes the bug where even after clicking elsewhere, the old
typeahead menu continued showing and on making a selection, the text
was inserted at the wrong (new) position.
Fixes: #21302.
The upload spinners for all of the image upload widgets were in
wrong alignment due to the use of magic numbers to center them.
This commit replaces the above mentioned approach with the use
of flexbox to fix alignment issues across all the image upload widgets.
Due to differences in length of the words for different languages
there were alignment issues in the organization profile settings.
This commit uses flexbox to ensure that the alignment stays correct
for any changes in language/word length.
Fixes#21385
The ready method was deprecated in jQuery 3.0, because its behavior
has nothing to do with the selector; it always waits for the page to
become ready, not a specific element.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
It was broken by commit f5fbf5f0e0
“change_password: Migrate modal to dialog_widget” (#20193), because
the new_password input didn’t exist when we tried to install an event
handler for it.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Co-authored-by: Steve Howell <showell@zulip.com>
Co-authored-by: Tim Abbott <tabbott@zulip.com>
This commit adds the backend functionality to
mark messages as unread through update_message_flags
with `unread` flag and `remove` operation.
We also manage incoming events in the webapp.
Tweaked by tabbott to simplify the implementation and add an API
feature level update to the documentation.
This commit was originally drafted by showell, and showell
also finalized the changes. Many thanks to Suyash here for
the main work here, which was to get all the tests and
documentation work moving forward.
Previously, we did not clear the resolved topic warning when reopening
the compose box after sending a emssage. This was a latent bug before
the previous commit, since the resolve topic was always displayed when
the compose box was pointed at a resolved topic before the previous
commit.
The resolve topic warning can feel like clutter in the event that the
compose box is empty (which often occurs when the user has no intent
to send a message), so we configure the validation logic to only
display the notice when the compose box is non-empty.
We take some care to minimize work the function is doing, beacuse it
is called on every keystroke in the compose box.
Fixes: #21155.
Make `compose_control_menu_wrapper` clickable and allow tab focus
on it. Disable tab focus on `compose_control_menu` icon. Fix outline
for `compose_control_menu_wrapper`.
Extend out custom outline property to all `[role="button"]` elements.
The 3 instances of dropdown_list_widget using the `label` property had
different design than the rest of all of our dropdowns, in that the
label was on the same line as the dropdown.
Fix this by adjusting the `label` option to use our standard
`dropdown-title` CSS class.
Also remove the colons in the labels.
I confirmed that these were the only instances of this widget using
the label feature.
Fixes#20415.
The previous icon had a slight asymmetry, some not-quite-straight
lines, and curves with an excessive number of nodes resulting from
some kind of vector → raster → vector workflow. Rebuild it from
scratch. This will be visually equivalent but render more
efficiently.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
The most plausible situations through which one would press these
hotkeys with the compose box still open are accidents (basically,
you're trying to type but the browser focus is unexpectedly not in the
compose textarea).
So we disable these keyboard shortcuts when the compose box is open,
regardless of where keyboard focus lies.
Fixes#21128.
Starting composing a message to a new recipient will clear the compose
box. Previously, we were saving drafts before doing so only in the
compose_actions.respond_to_message code path (i.e. when starting a
reply). Logically, this behavior should apply regardless of why we're
initiating a new message, so it belongs in compose_actions.start.
Fixes#21128.
Fixes#21171.
This class was leftover from a very old version of this design, and
had the side effect of settings `overflow: hidden` on the panel.
This, in turn, resulted in the focus outlines for clicking on
checkboxes looking broken.
Previously, these two headers were inconsistent with the rest of the
application, and with "Edit subscribers". We make them the same as
"Edit subscribers".
In "stream_types.hbs"
For "Who can access the stream?" and "Who can post to the stream?" replace
"h4" with "label" to make the for smaller and to remove boldness.
For "Message retention for stream" replace the "h4" with "label"
and add class="stream-title".
In "subscriptions.css":
Add "margin:25px auto" to "#announce-new-stream" to ensure equal
gaps above and below it.
Reduce margin and paddings for ".radio-input-parent".
For "select" set "width: fit-content" and
"height: fit-content" to ensure that the text in the
dropdown is clearly visible.
Fixes: #21322
In stream edit and stream create replace the existing checkbox
format for choosing "stream post policy" with dropdown widget.
In "stream_types.hbs" implement the dropdown menu and remove
the checkbox format for selecting "stream post policy".
In "stream_create.js" and "stream_edit.js" edit the code for
"stream_post_policy" to extract the "stream post policy" value
from the dropdown menu after submitting the form.
In "stream_data.js/stream_post_policy_values", change, the object to match
the following order and description of these policies:
1. Everyone [Default]
2. Admins, moderators and full members
3. Admins and moderators
4. Admins only
This sorts from least to most restrictive.
This commit fixes the issue where the delete (x) button on the
top right corner of the profile picture section remains hidden
even when a hover action is performed on the profile photo.
We loop through edit history entries and see if any of them
are more interesting than a (un)resolve topic edit, extending
the existing loop we had.
We also update the associated node tests.
Fixes#19919.
Co-authored by: Lauryn Menard <lauryn@zulip.com>
Updates the simulated edit history entries that are saved when
`update_messages` events are received for the modern data
structure on the server for `message.edit_history` entries.
Also cleans up a misnamed field in said entries, `edited_by`.
Uses the `rendering_only` field in the `update_message` event
to filter the addition of `last_edit_timestamp` to the message,
which is what triggers the addition of an `Edited` notification
when a message is rerendered in the web app.
Also, removes the deletion of `msg.last_edit_timestr` since this is
regenerated every time the message is rendered, and so it did nothing
beyond confusing the code.
We already show the error if topic input is empty and it is
not allowed to send messages without topic in the organization,
and this commit also shows error when topic is "(no topic)".
The topic is set to "(no topic)" when someone sends a message
with empty topic input box and when it is allowed to send message
without topics in the organization.
This is not ideal behavior as we may want to treat "(no topic)"
differently from empty topic, but we can fix this in future and
this commit can be a short term fix.
Fixes#21344.
We have two different frontend implementations of computing the
un-resolved form of a topic name, and they have a subtle -- but
intentional -- difference in behavior.
Factor them both out into the resolve_topic module, along with
their inverse, and with comments and tests.
These two conditionals are each relying on the other to trigger
on the same condition, and to do complementary things. Move them
together to a single place so that that relationship is easy to see,
and to refactor.
The most notable change here is that when you are adding
subscribers to a stream as part of creating the stream,
you can now use the same essential pill-based UI for
adding users as we do when you edit subscribers for an
existing stream.
We don't try to exactly mimic the edit-stream UI or
implementation, since when you are adding subscribers
during create-stream, we are just updating a list in
memory, whereas in the edit-stream UI, we immediately
send info to the server.
Fixes#20499
The effective date on the DPA should have been February 7, because we
didn't actually update the zulip.com website until that day.
(This commit was added to the internal zulip.com branch during
deployment of the last DPA update, so users always saw the correct
information).
This unfortunately requires somewhat ugly duplicated code, but I think
it's the best option for now.
I expect we will somewhat soon work on the transition to no longer
have two duplicate fetches here, and doing so will let us remove this
secondary code path.
Fixes#21304.
I made the header sections above all our settings
panel lists more consistent.
Before this change:
* some lists had titles, others didn't
* the placement of the filter box was random
* alerts strangely went between the filter box
and the list
* filter boxes were too large
* CSS was haphazard
* forms were squished against tables
Now all the settings with list have consistent
HTML, CSS, and look-and-feel in the area directly above
their list of items.
With the exception of Custom Profile Fields, all the
lists with headers above them happen to be based on
ListWidget, but the header styling is not coupled
to ListWidget, because we want consistent headers
even if Custom Profile Fields has a non-ListWidget
list (due to its drag&drop features).
Previously, this had different hover behavior from the adjacent
elements, which seems like a bug.
The CSS for this component is shared with Recent Topics; we migrate
the styling for on_hover_topic_read for consistency.
Fixes#21273.
Because Zulip Mobile supports some older iOS browser versions that
don't have replaceAll support yet, and mobile is averse to doing the
infrastructure work required to add a, polyfill we avoid using them in
the shared module for now.
See https://caniuse.com/mdn-javascript_builtins_string_replaceall
Prefer a regexp match over using String#replace to strip expected
prefixes and suffixes because (a) it implicitly verifies that the
input has the expected format and (b) it won’t unexpectedly strip from
the middle of the string.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
You generally only need to type a few characters to filter
down to just a few folks, even in gigantic realms.
I tried not to make it **too** small, just in case, but
the default width was kind of gaudy.
The header was more confusing than helpful, and we
want the create-stream UI to be less cluttered.
We don't really need the help-center text here, since
we already have ? icons next to the relevant headings
for the sub-sections.
We kill off some CSS, but we won't kill off stream-title
until the big upcoming changes for stream pills.
Muted streams are now greyed out in the personal settings,
also changes to the notification settings of a muted stream are
not possible anymore.
Also, add a bell-slash icon after the stream name of muted streams,
clicking on it unmutes the stream.
Fixes#19780.
Previously, updating the UI when streams are muted was split between
two places: The server_events.js code path, which updated the checkbox
state and other parts of the app, and checkbox click handler, which
toggled the disabling of the notification settings checkboxes.
Move these to all live in a single place.
With the recent changes to lightbox image handling in #21145 and #20788
it is no longer necessary to have panning and zooming disabled by
default. This commit removes the enable/disable button and instead
replaces it with a "Reset Image" button, and enables panning and zooming
as the default state of the lightbox.
This commit attempts to prevent images with long filenames,
descriptions, or author names displayed in the lightbox from altering
the layout of the page.
It also adds a title prop to both the filename and author, allowing a
user to hover and see a tooltip of the full text in the case where the
text is truncated.
Fixes#21058.
Make the unread marker lines at the side of messages continuous by
adding "height: 100%" to ".unread-marker".
This provides a nicer visual experience by not highlighting the
boundaries between messages. (One can see that information using the
timestamps or by moving the selection cursor, where appropriate).
Fixes#20981.
Hides 'disable' button of any kind when nothing is selected
in dropdown list widgets by removing ':enabled' selector from
the button, the button is not actually a button, it's an <a> tag which
doesn't support "disabled" attribute.
Fixes part of #20831.
We use Label as the heading for the field label column in the custom profile
fields table; but for some reason the edit UI called this "Name" instead.
Fixes#21260.
It's 2022 and the WHATWG no longer recognizes the term URI. Everything
is now a URL or a type of URL. Which is great because it's way less
confusing. Details here:
https://url.spec.whatwg.org/
Moves hash_util.by_stream_uri and hash_util.by_stream_topic_uri to
internal_url so they can be used by external codebases. Due to these
functions being called in many places in the web codebase, wrappers
for both functions are left in hash_util in order to keep these
calls simple.
Also adds test for explicitly testing each function.
Move hash_util.encode_stream_id to internal_url, so it can be shared
with external codebases. Also add a test that explicitly tests escaping
special characters in stream names.
Move stream_data.id_to_slug to internal_url, making it shareable. The
function has been renamed to stream_id_to_slug to reflect that it
operates on a stream id.
Moves the encodeHashComponent and decodeHashComponent functions out of
hash_util and into internal_url which belongs to shared. This is to
accommodate sharing of this code with mobile or any other codebases that
do not wish to duplicate logic.
In order to accommodate the sharing of hash_util with other codebases
including mobile, UI and web specific code should be removed. In this
commit, we remove exception handling for the decodeHashComponent
function and instead add the UI handling of it further up the call
stack.
The stream_data.id_to_slug and stream_data.name_to_slug
functions mistakenly used Javascript's String.replace method,
this commit changes it to use String.replaceAll, the result
being slugs generated from streams with names greater than
2 words are now properly formatted.
An attacker could maliciously craft a full name for their account and
send messages to a topic with several participants; a victim who then
opens an overflow tooltip including this full name on the recent
topics page could trigger execution of JavaScript code controlled by
the attacker.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Inherit uses the settings of the parent element; we actually want to
just undo the `display: none` we'd set for this CSS property, which is
what revert is for.
The previous `display: unset` logic didn't work with dividers in the
gear menu. This new version should be correct -- what we want to do
here is just override the `display: none` default for this class, not
revert to the default browser styling for that element type.
In open_edit_form, we had an initialization order bug where we called
set_up_external_account_field_edit_form, which clears the field name
field if the external account is of the "custom" type, after
populating the initial values for edit form.
This resulted in these fields being displayed as empty in the UI for
this field type. Fix the issue by reordering the initialization.
Fixes: #21262.
This reverts commit f3964673e7.
It broke drafts_scroll by confusing jQuery object APIs with DOM
element APIs.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This should increase its visual priority in the UI. We plan to move
"Private messages" to a different component more similar to STREAMS
soon.
Fixes#20869.
This commit removes the unnecessary `data-list-widget` attribute
present in the <div> and <tbody> tag for muted_topics and muted_users table.
It became unnecessary/useless in 19cf6d0e04 and
then was renamed while still useless.
Also uses the correct variable name `muted_topic` and `muted_user`
instead of `muted_topics` and `muted_users` to render a item of their list
in DOM through Listwidget.
This changes the method of rendering list of alert words in DOM,
earlier it was rendered using 'for' loop over the array of alert_words
which is now changed to render using ListWidget, which gets a array
of objects from get_word_list() in alert_words.js.
The use of ListWidget helps to define a parent_container and $container
in table-body of alert-words-table using which we can now apply sorting over
alert words with the help of handle_sort() function in list_widget.js
Changed the method of adding alert_word_settings_item row in table body
through {{#with}} loop because of rendering through ListWidget, which was done
earlier using for loop over each alert-word in while rendering the list.
this commit also mocks template of render_alert_word_item
while mocking ListWidget.create() function in render_alert_words_ui().
and checks that ListWidget.create() is not called when variable `loaded`
is set as false.
Fixes#21142.
We follow how other apps present older messages, e.g. Gmail,
Facebook Messenger, etc. display it.
Specifically, the logic we use is:
If the time is <24hr ago, show an absolute time, like "21:30" (or "9:30pm").
Otherwise, show what day it was, and not a time
If the day was yesterday, say "Yesterday".
Otherwise, if it was <7 days ago, say the day of week, like "Friday".
Otherwise, if it was <1 year ago, say the month and day, like "Sep 6".
Otherwise, say the year, month, and day, like "Sep 9, 2020".
With some tweaks from Tim Abbott to better handle the future case.
Fixes#19775
Previously, update_user_data was called when deactivating
bots, but it was removed in 58b612a4f0.
Now, update_user_data is only called for 'type="realm", op="update"'
events, but these events are not sent when deactivating or
reactivating a user or bot, so this code is not used.
This commit changes the code to call update_view_on_deactivate function
from server_events_dispatch.js on receiving the user/bot remove event
instead of having it repeatedly in the success_continuation method
of click handlers.
We also add check to make sure we return early if the relevant settings
page is not opened yet.
This commit adds a width of 10px to fa-square and fa-check-square
icons in recent-topics table, so that on toggling between these icons
we can prevent the change in width of the whole button to make it look
good visually.
This commit adds option to deactivate user to "Manage user" modal.
A modal is opened on clicking the option to confirm the deactivation
and the "Manage user" modal is closed.
The error from the server, if any, is shown in the modal itself
and in case deactivation is done successfully, the modal is closed.
Fixes#18944.
We pass handle_confirm function as an argument to confirm_deactivation
because we will use confirm_deactivation to deactivate the user from
user-info popover and the popover case will have a different handle_confirm
function (which is called after clicking "Confirm" button of the modal)
since error handling in that case will be different as there will be no
overlay in the background.
This commit adds a method to detect whether the draggable element has
moved out of view and if it has, move it back into view.
The panzoom library does have a `bounds` option that is supposed to
provide the functionality, but at the time of the commit it does not
appear to work correctly. Upstream bug:
https://github.com/anvaka/panzoom/issues/112
This PR changes the library used for panning and zooming in the lightbox
module from timmywil/panzoom to avanka/panzoom.
The original (timmywil) version of the library contains a bug where if
you have a high resolution touchpad and Firefox and you zoom in and out
repeatedly on an image, the image may drift. avanka/panzoom does not
appear to display this behavior.
Restores the behaviour from before 5f83bc5cfe, where clicking
outside the image closes the lightbox, primarily by way of swapping
out the panzoom library.
Fixes: #21163.
We are going to move to this code organization for
managing streams:
stream_create.js
stream_create_subscribers.js
stream_edit.js
stream_edit_subscribers.js
The modules stream_create.js and stream_edit.js historically
manage the entire process of creating and editing stream
data (respectively).
Going forward both will delegate most of the subscriber-specific
pieces to either stream_create_subscribers or stream_edit_subscribers.
The stream_*_subscribers modules will be somewhat similar in
nature, but the way that we manage subscribers at creation time
is a bit different than how we manage subscribers at edit time.
This will help us avoid some duplicate code when
we use input pills for stream-create.
See the long comment in set_up_handlers() for
more context.
We also rename:
submit_add_subscriber_form -> subscribe_new_users
Ideally set_up_handlers() would also extract the
concept of clearing the pills as soon as you either
hit enter or clicked on the Add button, but our
current paradigm for clearing pills when you edit
subscribers for an existing stream on the Subscribers
tab is that we wait for the server to acknowledge
the request. I believe this is a bit of a misfeature,
but I am punting on that change for now.
This is mostly a pure code move. A few small tweaks:
* The create() function is new.
* The new module doesn't assume a `pill_widget`
global.
This module represents the truly re-usable code
that can be shared during these two user actions:
* edit-stream subscribers (now)
* create-stream subscribers (future)
In both situations the input pill has (or will have)
essentially the same behavior, and the next commit
will tighten up the abstraction.
(The two processes will both also use fairly similar
ListWidgets, but the mechanics of managing the list
are going to be different, so we do not intend
to keep around stream_subscribers_ui in its current
name. More on that later.)
This simplifies some of our dependencies.
As an example, we really don't want compose.js
to depend on stream_subscribers_ui.js, since
the former doesn't use any actual UI code from
the latter.
We also rename the two functions here:
invite_user_to_stream -> add_user_ids_to_stream
remove_user_from_stream -> remove_user_id_from_stream
(The notion of "inviting" somebody to a stream is
somewhat misleading, since there is really no invitation
mechanism; you just add them.)
Apart from naming changes this is a verbatim code move.
Finally, we eliminate a little bit of test cruft--the
`override` helper already ensures that a function gets
called at least once during a test.
Edit history of message was rendered directly without passing
it through rendered_markdown.js. Due to this several visual
features for dynamic elements like time, spoilers, mentions
etc were not available.
To fix above issues we pass the content of edit-history
through rendered_markdown before showing edit history modal.
Fixes: #16029.
Improves rendering of drafts to make it look more closer
to normal messages. This is done by passing the draft content
through rendered_markdown so that dynamic elements in the content
get updated before showing drafts modal.
Moves the profile avatar to the top when the viewport is narrowed down.
Tweaked by tabbott to add the 20px bottom margin in a more consistent
way, which also lets us deduplicate some code.
Fixes#21000.
d6fb439c7a removed the option to remove owner from the edit form available
to admins, but the option was still present in the edit form available to
the owner of bots in "Bots" section of personal settings. This commit
removes the option from form in "Bots" section of personal settings as well.
Previousy, we used to show or hide the digest weekday setting after
saving the emails setting, but now we show/hide as soon as we check
or uncheck the email setting checkbox like we do for other settings.
Notifies user when messages are not being marked as read through a
banner that lets them mark all messages in the narrow as read. Note
that the banner is only displayed if the user's actions, like
scrolling, would've actually marked the messages as read.
This avoids distracting the user when viewing a thread they've already
read.
tabbott has verified that if new messages come in, the banner will reappear.
Fixes: #18768.
There are a few instances where we check if messages can be marked
read and mark that list as read when scrolled to bottom. Using
this would be nicer and also this function can be extended later to
display a banner when messages are not being marked.
The class `sidebar-topic-check` has a minimum width assigned for the
`topic-resolved` icon to create an appropriate space for that column
whether or not there are resolved topics present.
Add a corresponding `margin-left` to align `more topics`
appropriately.
Show/hide scroll to bottom button when the last message is
not visible in the current scroll position.
We adjust the bottom offset of the button based on compose box
height.
Fixes#19862
We save the preferred theme in localstorage so that user doesn't
have to re-select the theme on every reload. Users on slow
computers might see flash of a theme change, if it happens.
This change was not aimed at popovers that use tippy. Since
popovers use light theme and tooltips don't, we use this
`not[data-theme]` selector to exclude popovers from being
affected by this change.
For filters that cannot be applied locally, we don't know if the
messages are still a part of the filter. So, we remove the
existing message that were updated and let `maybe_add_narrowed_messages`
treat them all as new messages to the filter.
This fixes the bug where existing messages that were present in
the narrow were not updated.
In the dark theme, disable the hover behavior to display sorting options
for actions column in tables (Which doesn't support this).
Matches existing behavior in light theme.
Fixes: #21137
Added a property `mouse_moved_since_typeahead` to the typeahead class
which tracks whether the mouse has been moved since the typeahead
menu appeared.
The hovered over menu item is highlighted on `mouseenter` only if
`mouseMoved` is true. Otherwise, the cursor is hidden temporarily.
Code substantially reorganized by tabbott.
Fixes: #21018.
For our Subscribers tab we want to enclose our
add-subscriber widget in a form for now, and we
continue to do so, but now we have the form tag
getting created in the parent template, not the
child.
Here is why:
We want to re-use our add-subscriber widget in an
upcoming commit for when you create streams.
In our create-stream UI, there is already an outer
<form>...</form> section of the HTML for the entire
process of creating a stream.
HTML does not yet you nest forms, and even though
browsers just silently ignore an inner form, we won't
want to create semantically incorrect HTML.
Therefore, we want the child template not to have
the form tags around them.
It's possible that we don't really even want to
enclose the input-pill widget and Add button inside
a form for the Subscribers tab, but tweaking that
for now is too risky. (We don't really take advantage
of the form tag in any meaningful way, since we
don't directly submit form data to the server, and
we can't use a single submit handler for the Enter
key and Add button due to some magic in our input
pills.)
We want to avoid submit handlers here, because we may
have embedded widgets that have their own forms or
buttons.
We use "finalize" here to distinguish the two Create
buttons related to streams. You hit one button to
start the UI and then the second button to finalize
the process.
I also fix the bad test idiom of clicking on the
sea-green button.
You don't start auto-completing user groups with an @,
so the previous placeholder text made no sense.
There might be a better way to do autocomplete in
these add-subscriber input pills, but that is beyond
the scope of my current efforts.
This adds tabindex='0' in anchor tags for allowing the message menu
popover box to be focusable using hotkey 'i' through keyboard.
This is a necessary follow up to
729c09074a, which removed the href
attribute from anchor tags to which click-handlers were attached,
which resulted in making them non-focusable as jQuery doesn't allow
anchor tags to be focusable without tab-index or href attribute.
Fixes#21125.
This seems to have no negative effect, and substantially improves the
visuals in situations where we're displaying a user's name.
While we're at it, switch to a relative font size.
When viewing a narrow such as a search or `sender:` view, where
consecutive messages in the view may not be consecutive in their
original stream/topic context, we should avoid displaying the messages
with a shared sender/recipient bar header, as that creates the
incorrect perception that they are consecutive.
Back in 2013 (bc8bc8567b), we
implemented this via the collapse_messages flag, but it appears more
recent refactoring (no more recent than
dbffb2a614) made it always true.
The original logic was incorrect, in that it only considered full-text
search views, and not other views with this property.
I originally planned to use the existing logic for
can_mark_message_read designed for this purpose, but I think there
might be product reasons why might want the logic to be independent.
Removes the 5px `margin-right` on images, replacing it
with a 5px `margin-left`. This change aligns the images
with the message content while making sure they do not
stick stick together in other layouts.
Add a margin below the subscription link for it to be visible when we
hover over links, where the browser will display the URL in the
bottom-left corner of the screen.
Previously the emoji_status set by the user would only be seen in a
few places, it was decided that it would be useful to show the
emoji_status in a couple of other additional places as well.
As such this commit uses the status_emoji template to show the status
emoji in the compose_pm typeahead and the mentions typeahead.
Status emoji changes do not live update these, but neither do user
renames, so there's bigger problems if that's a concern.
Fixes: #19865.
Previously the emoji_status set by the user would only be seen in a
few places, it was decided that it would be useful to show the
emoji_status in a couple of other additional places as well.
As such this commit uses the status_emoji template to show the status
emoji in the compose_pm pills. Due to the fact that we use the same
pills system to render in the user_group, we need to add a
conditional to prevent rendering there since the user status is not
valuable there.
Status emoji changes do not live update these, but neither do user
renames, so there's bigger problems if that's a concern.
Previously the emoji_status set by the user would only be seen a few
places, it was decided that it would be useful to show the
emoji_status in a few additional other places as well.
Use the status_emoji template to show the status emoji in the
message_body and also implement live update behavior.
With refactor and minor edits by Yash RE.
Co-authored-by: YashRE42 <33805964+YashRE42@users.noreply.github.com>
Previously the emoji_status set by the user would only be seen in the
buddy list, it was decided that it would be useful to show the
emoji_status in other places as well.
As such this commit uses the status_emoji template to show the status
emoji in the PM list and also implements live update behavior.
With refactor and minor edits by Yash RE.
Co-authored-by: YashRE42 <33805964+YashRE42@users.noreply.github.com>
Previously, when the user clicked the `Add streams` icon in the
streams list sidebar, we provided a popover offering to create or
subscribe. This was confusing for users who did not have permission
to create streams.
Redirect users that don't have stream creation permissions
directly to browse streams without going through this popover.
Fixes: #20676.
Previously, if the user changes any stream color and updates it back
to the default color without reopening the change color popover, the
second color change didn't take effect.
Fix bug by destroying the colorpicker object and rebuilding it again
every time a color change is triggered by the confirm button.
Fixes: #21055
Previously, we would call `rerender_messages_view()` in order to
rerender messages after user renames or avatar updates. This would
lead to rerendering the entire message list for every change,
regardless of whether any specific message had changed or not.
This used to be acceptable because user renames and avatar updates
were rare events, however, as we plan to show user status emoji near
user names and updates to those would be more frequent than is
affordable, this commit implements
`rerender_messages_view_for_user(user_id)` which only rerenders
messages which have actually been changed.
This commit is, thus, both an optimisation for the existing code and a
prep-commit for the user status emoji.
Previously, we used to only calculate sender_is_bot, sender_is_guest,
small_avatar_url and background_color on the message_container via
build_message_groups (ie via .render, which also gets called from
.rerender_with_target_scrolltop).
This would mean that if we tried to use `_rerender_message` to update
just a single message (which is something we'd like to do, in order to
make rerenders more efficient), these values would not update.
(This could lead to avatars not light-updating properly).
As such, this commit moves assignment of these values into
`set_calculated_message_container_variables`.
This reverts commit 8e06335788 (#21048).
It regressed the ↑ and ↓ keys because drafts.drafts_scroll was not
updated to use ui.get_scroll_element. Also, styling the native
scrollbar as hidden is not the right workaround because the hidden
native scrollbar still exists and can be scrolled independently of the
SimpleBar.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
In the topic changing UI, the 'Change later messages to this topic'
and other options in the drop down were cut off when selected in some
languages like Russian.
Make the selection box width adjust appropriately according to the
length of the text, and also place it on its own line unconditionally.
users.
With tweaks by tabbott to use the same approach we already use in the
"Move topic" modal to have the bottom margin for the color block match
that of the dropdown_list_widget itself, of having them share CSS.
Fixes#19739.
There is no problem in behavior of browser back button we open stream settings
overlay using UI elements since they are appropriately linked to "#streams/all",
"#streams/subscribed" and "#streams/new", but someone can directly go to a
link with "#streams" and in this case we want to fix the browser back button.
This commit replaces "#streams" entry with "#streams/subscribed" which is the
default section opened, such that pressing back when on "#streams/subscribed"
does not go to "#streams" and instead go back actually.
When we open settings overlay we first go to "#settings" hash and
then to "#settings/profile" or hash according to the last opened
section. Now when a user presses back button from "#settings/profile"
it goes to "#settings" which agains then changes to "#settings/profile"
and thus the browser back button does not work as expected.
This commit fixes this by replacing the "#settings" entry in history
with "#settings/profile" or to the hash as per last opened section,
using replaceState and thus there is no entry of "#settings" in history.
Fixes#19820.
We use button element instead of <a> element for the button used to change
stream permission. This change fixes the focus problem where the container
was focussed when closing the permission modal.
The problem here was because Micromodal focuses the element which was just
focused before opening the modal, on closing the modal. And in this case the
focused element before opening the modal was the "simplebar-content-wrapper"
element as <a> tah without href is not focusable element.
Related issue - #20223.
As seen in
https://chat.zulip.org/#narrow/stream/9-issues/topic/edit.20history.20bug/near/1320430,
clicking such a link takes you to the user's default view if the click
handler throws an exception before doing preventDefault().
There hrefs also have the negative effect of having your browser claim
that clicking the link will navigate you to the default view, which it
won't.
Comes with a linter rule to prevent future instances, since it seems
there are some recently added ones, though they are likely the result
of copy/paste.
Apparently, we were only dispalying the edit history option in the
message actions popover if the topic/content were changed. Fix this by
adding a small adjustment to the conditional to include stream
changes correctly.
Currently the emoji_status set by the user is only seen in the buddy
list, it would be useful to show the emoji_status in other places as
well.
As such this commit does the prep work of extracting a template which
will be used in all places that need to show the status emoji.
With refactor and minor edits by Yash RE.
Co-authored-by: YashRE42 <33805964+YashRE42@users.noreply.github.com>
Currently, the emoji_status set by the user is only seen in the buddy
list, it would be useful to show the emoji_status in other places as
well.
As such this commit does the prep work of decoupling the
selected_emoji style in user_status.css from the .status_emoji
style... by having it always override the value of "top".
I also clean up all the mutations of `user_ids`
in the calling code. We now have:
pill_user_ids
active_user_ids
user_id_set
user_ids
The new function is exported in anticipation of using
it from stream_create.js.
User should be able to tab from topic/pm input to textarea and back.
Moving `compose_top_right` button before the stream, topic and PM
input structurally in DOM but keeping them visually in the same
place, allows us to do so.
This is an unpredictable piece of css that shouldn't be part of
the code. It was introduced earlier in
04ece5e5c5
for `open-source` content which has been completely replaced.
The clarification is in Section 4.1:
Previously: ... from time to time engage additional third parties for
the purpose of providing the Services, including without limitation
the processing of Personal Data.
New: ... from time to time engage additional third parties for the
purpose of providing the Services, including without limitation the
processing of Personal Data, in accordance with Section 4.2 below.
This commit adds a method of marking an overlay as being meant to be
left open despite click events triggering that would normally close it.
This is to prevent the case where a user drags an image and "unclicks"
in an area where normally clicking would close the overlay.
This commit attempts to revert the lightbox state (at least
the pan/zoom part of it) when the lightbox is closed. The open()
function has been turned into a factory function so that the zoom
control which is instantiated on initialization of the lightbox can be
passed in to the on_close handler of overlay.open().
This PR changes how the Pan & Zoom feature of images displayed in the
attachment lightbox are handled.
The existing method of using a canvas element is replaced by the Panzoom
library (timmywil/panzoom). This library is lightweight and has 0
transitive dependencies.
This fixes#20759 where the issue is that the viewport of a zoomed image
was not expanding to fill the available space on the page. Switching to
this new library also solves several other UX issues:
* Images are no longer blurred when in Pan & Zoom mode.
* The zoom behavior itself uses focal point zooming: zooming occurs
where the cursor is on the image instead of at the center of the
image, reducing the need for extra panning.
* CSS transitions are used for a more visually pleasing experience
when switching images, toggling zoom off, etc.
* The library has the potential to open other file types which
leaves that option open for us in the future.
Sahil Batra
Raghav Luthra
George A. Michel
Anders Kaseorg
Austin Riba
somesh202
aparna-bhatt
Sdrummolo
jai2201
Tim Abbott
Aman Agrawal
Greg Price
Steve Howell
Greg Price
Archisman Das
NerdyLucifer
Palash
Heidi Ahlberg
Alya Abbott
yogesh sirsat
YashRE42
ditsuke
Alex Vandiver
Rishabh-792
SantamRC
My-Name-Is-Nabil
Biki-das
Lauryn Menard
Ganesh Pawar
strifel
Nikhil Maske
N-Shar-ma
sayamsamal
Suyash Vardhan Mathur
Lauryn Menard
prashantpaidi
Greg Price
Dinesh
Junchen Liu
Julia Bichler
Austin Riba
Yogesh Sirsat
Mateusz Mandera
Purushottam Tiwari
Jai soni
AnushaNathRoy
Mr.mad
Parth
